From dhcwg-admin@ietf.org Sun Nov 2 19:03:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00176; Sun, 2 Nov 2003 19:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGSBQ-0002Ft-Jo; Sun, 02 Nov 2003 19:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGSB2-0002FX-N3 for dhcwg@optimus.ietf.org; Sun, 02 Nov 2003 19:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00144 for ; Sun, 2 Nov 2003 19:02:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGSAu-0004Sl-00 for dhcwg@ietf.org; Sun, 02 Nov 2003 19:02:28 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AGSAt-0004SH-00 for dhcwg@ietf.org; Sun, 02 Nov 2003 19:02:27 -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 <0HNR0044D1F2IU@mailout2.samsung.com> for dhcwg@ietf.org; Mon, 03 Nov 2003 09:01:50 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNR00CHK1D126@mailout2.samsung.com> for dhcwg@ietf.org; Mon, 03 Nov 2003 09:00:38 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNR00L501D1WB@mmp1.samsung.com> for dhcwg@ietf.org; Mon, 03 Nov 2003 09:00:37 +0900 (KST) Date: Mon, 03 Nov 2003 09:00:58 +0900 From: Soohong Daniel Park To: dhcwg@ietf.org Cc: "'Vijayabhaskar A K'" , "'Soohong Daniel Park'" Message-id: <002b01c3a19d$8f9749e0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_9F5JodF+Vo7GdtZeZfX1Xw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [dhcwg] [I-D] DHCPv6 support for IPv6 Transition Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_9F5JodF+Vo7GdtZeZfX1Xw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All I am attaching a new draft dealing with IPv6 transition issue. " DHCPv6 support for IPv6 Transition" I could not submit the draft to ID queue, as the deadline has crossed. Please go through this draft and let me know your comments. The abstract of this draft is given below Abstract For the newly deployed IPv6 networks to interoperate with vastly deployed IPv4 networks, various transition mechanisms had been proposed. Two such methods are configured tunnels [2] and 6to4 routing [3]. This document provides a mechanism by which the DHCPv6 [1] servers can provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. This documents also explains the mechanism by which the 6to4 hosts are allocated with 6to4 addresses needed for 6to4 tunneling [3]. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics --Boundary_(ID_9F5JodF+Vo7GdtZeZfX1Xw) Content-type: text/plain; name=draft-ietf-dhc-dhcpv6-ipv6trans-00.txt.txt Content-disposition: attachment; filename=draft-ietf-dhc-dhcpv6-ipv6trans-00.txt.txt Content-Transfer-Encoding: 7BIT Network Working Group A.K. Vijayabhaskar Internet-Draft Hewlett-Packard Expires : May 2004 S. Daniel Park SAMSUNG Electronics November 2003 DHCPv6 support for IPv6 Transition draft-ietf-dhc-dhcpv6-ipv6trans-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract For the newly deployed IPv6 networks to interoperate with vastly deployed IPv4 networks, various transition mechanisms had been proposed. Two such methods are configured tunnels [2] and 6to4 routing [3]. This document provides a mechanism by which the DHCPv6 [1] servers can provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. This documents also explains the mechanism by which the 6to4 hosts are allocated with 6to4 addresses needed for 6to4 tunneling [3]. Vijay, Park Expires May 2004 [Page 1] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 1. Introduction In the initial deployment of IPv6, the IPv6 nodes may need to communicate with the other IPv6 nodes via IPv4 networks. Configured tunnels [2] provide a way to encapsulate the IPv6 packets in IPv4 packets and tunnel them in the IPv4 network. 6to4 routing [3] does the same kind of tunneling, but, without the need of configured tunnels. But, the hosts are needed to have a special type of addresses called 6to4 addresses of prefix 2002::/16. This document defines a new option called Configured Tunnel End Point by which the server can notify the client with the list of end point of the configured tunnels to various IPv6 networks separated by the IPv4 networks. This document defines another option called Identity Association for 6to4 addresses. This option is used to configure the clients with 6to4 addresses needed for 6to4 routing [3]. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [4] 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in "Terminology" section of the DHCPv6 specification [1]. 4. Configured Tunnel End Point Option The Configured Tunnel End Point Option gives the information to the clients about the Configured Tunnel End Point [2] to be contacted for reaching the nodes in the various IPv6 networks which are separated by IPv4 networks. The clients are expected to install these routes in their machines. The format of the Configured Tunnel End Point Option is as shown below: Vijay, Park Expires May 2004 [Page 2] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CTEP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | | +-+-+-+-+-+-+-+-+-+ | | | | Destination Prefix (16 bytes) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+ | | Configured TEP Address (16 bytes) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Destination Prefix (16 bytes) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Configured TEP Address (16 bytes) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_CTEP (TBD) option-len: Total length of the prefix-len, Destination Prefix and Configured Tunnel Address lists in octets; It should be a multiple of 33. prefix-len: prefix length of the Destination Prefix Destination Prefix: IPv6 Prefix; The initial (MSB) 'prefix-len' bytes should be 1 and remaining bytes should be 0. Vijay, Park Expires May 2004 [Page 3] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 Configured TEP Address: IPv6 Address of the Configured TEP. The clients are expected to install the routes identified by the tuples in their machines once they receive this option from the server. 5. Identity Association for 6to4 Addresses Option (IA_6TO4) This document defines another option called Identity Association for 6to4 [3] addresses (IA_6TO4). This option carries parameters associated with IA_6TO4 and 6to4 addresses associated with the IA_6TO4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_6TO4 | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_6TO4-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_IA_6TO4 (TBD) option-len 12 + length of IA_6TO4-options field IAID The unique identifier for this IA_6TO4; the IAID must be unique among the identifiers for all of this client's IA_6TO4s. T1 The time at which the client contacts the server from which the 6to4 addresses in the IA_6TO4 were obtained to extend the lifetimes of the 6to4 addresses assigned to the IA_6TO4; T1 is a time duration relative to the current time Vijay, Park Expires May 2004 [Page 4] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 expressed in units of seconds T2 The time at which the client contacts any available server to extend the lifetimes of the 6to4 addresses assigned to the IA_6TO4; T2 is a time duration relative to the current time expressed in units of seconds IA_6TO4-options Options associated with this IA_6TO4. The IA_6TO4-options field encapsulates those options that are specific to this IA_6TO4. For example, all of the IA Address Options carrying the 6to4 addresses associated with this IA are in the IA_6TO4-options field. The clients are expected to configure the interface for which the DHCP Request was sent, with the 6to4 addresses. An IA_6TO4 option may only appear in the options area of a DHCPv6 message. A DHCPv6 message may contain multiple IA_6TO4 options. The status of any operations involving this IA_6TO4 is indicated in a Status Code Option [1] in the IA_6TO4-options field. Note that an IA_6TO4 has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the 6to4 addresses in an IA_6TO4 have expired, the IA_6TO4 can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA_6TO4. In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters. The client sets T1 and T2 to 0 if it has no preference for those values. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless those values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any 6to4 addresses in the IA_6TO4 before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the 6to4 addresses in the Vijay, Park Expires May 2004 [Page 5] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 IA, respectively. If the time at which the 6to4 addresses in an IA_6TO4 are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. 6. Client Behavior If the client's network support 6to4 routing and the client is interested in communicating with the IPv6 nodes connected by 6to4 routers, it can obtain the 6to4 addresses from the DHCPv6 server using IA_6TO4 option. The IA_6TO4 option is very similar to the IA_NA [1] in all aspects except IA_6TO4 carry 6to4 addresses in encapsulated IA address option. The request, renew, rebind, confirm, release and decline of IA_6TO4 is done in similar way as IA_NA. The handling of the error codes are also done in the similar way as IA_NA [1]. 7. Server Behavior The server SHOULD select 6to4 addresses for assignment to IA_6TO4 as per the mechanism specified in Section 11 (Selecting Addresses for Assignment to an IA) specified in DHCPv6 specification [1]. The server SHOULD assign 6to4 addresses to IA_6TO4 or return error codes in the very similar way as for IA_NA [1]. 8. Appearance of this option The Configured Tunnel End Point Option MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The option number of Configured Tunnel End Point option MAY appear in the Option Request Option [1] in the following messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. The Identity Association for 6to4 addresses option MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Confirm and Reply. 9. Security Considerations Vijay, Park Expires May 2004 [Page 6] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 The Configured Tunnel End Point Option may be used by an intruder DHCPv6 server to provide invalid configured tunnel end point. This makes the client unable to reach its destination IPv6 node. The Identity Association for 6to4 address option may be used by an intruder DHCPv6 server to allocate 6to4 addresses which may be incorrect or inappropriate to the client's link. This will result in the client unable to communicate to the IPv6 nodes connected through 6to4 routers. To avoid attacks through this option, the DHCPv6 client SHOULD use authenticated DHCP (see section "Authentication of DHCP messages" in the DHCPv6 specification [1]). 10. IANA Considerations IANA is requested to assign an option code to the following options from the option-code space defined in "DHCPv6 Options" section of the DHCPv6 specification [1]. Option Name Value Described in OPTION_CTEP TBD Section 4 OPTION_IA_6TO4 TBD Section 4 11. Normative References [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 12. Informative References [2] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [3] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Vijay, Park Expires May 2004 [Page 7] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 Authors' Addresses Vijayabhaskar A K Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053085 E-Mail: vijayak@india.hp.com Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416. Maetan-Dong, Paldal-Gu, Suwon, Gyeonggi-Do Korea Phone: +81-31-200-4508 E-Mail: soohong.park@samsung.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Vijay, Park Expires May 2004 [Page 8] Internet-Draft DHCPv6 support for IPv6 Transition November 2003 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. The idea of this specification is based on RFC 2937, September 2000. Vijay, Park Expires May 2004 [Page 9] --Boundary_(ID_9F5JodF+Vo7GdtZeZfX1Xw)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 3 05:46:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27027; Mon, 3 Nov 2003 05:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGcDh-0005VE-7l; Mon, 03 Nov 2003 05:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGcD9-0005UQ-0W for dhcwg@optimus.ietf.org; Mon, 03 Nov 2003 05:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27006 for ; Mon, 3 Nov 2003 05:45:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGcD5-0003Y2-00 for dhcwg@ietf.org; Mon, 03 Nov 2003 05:45:23 -0500 Received: from nt.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AGcD3-0003W5-00 for dhcwg@ietf.org; Mon, 03 Nov 2003 05:45:21 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119041>; Mon, 3 Nov 2003 11:37:54 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Nov 2003 11:41:42 +0100 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Date: Mon, 3 Nov 2003 11:41:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3A1F7.0C32B670" Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface Information Option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3A1F7.0C32B670 Content-Type: text/plain Hello DHC-WG, I seem to have missed the deadline for ID submission, but need some criticism/feedback on the issues described in the enclosed drafts. Please read through the documents and let me know your comments. The abstracts of these drafts are given here: -- DHCP Discovery Extensions -- This draft defines simple protocol enhancements to DHCP so that it can be used for the following applications: - Discovery of clients in the network - DHCP server redundancy - Server-initiated configuration of clients The discovery mechanism described here is built upon and coexists with BOOTP according to RFC 1542 and DHCP according to RFC 2131 and RFC 3203. It allows server-initiated communication to specific or all clients in the network, using the DHCP packet format. Other DHCP servers in the network can be provided with information about all existing client configurations and will therefore be able to take over if the main server fails. <> -- DHCP Interface Information Option -- This draft defines a new option to inform the server about the client's physical interface it is connected to. This information may be used together with the relay agent information option (RFC 3046) for the purpose of topology recognition. <> Best Regards, Markus Rentschler ------_=_NextPart_000_01C3A1F7.0C32B670 Content-Type: text/plain; name="draft-rentschler-dhc-discovery-00.txt" Content-Disposition: attachment; filename="draft-rentschler-dhc-discovery-00.txt" Content-Transfer-Encoding: quoted-printable DHC Markus Rentschler Internet Draft Hirschmann Electronics = =20 Expires: April 2004 November 2003 DHCP Discovery Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft defines simple protocol enhancements to DHCP so that it can be used for the following applications: - Discovery of clients in the network - DHCP server redundancy - Server-initiated configuration of clients The discovery mechanism described here is built upon and coexists with BOOTP according to RFC 1542 and DHCP according to RFC 2131=20 and RFC 3203. It allows server-initiated communication to specific or all clients=20 in the network, using the DHCP packet format. Other DHCP servers in the network can be provided with information about all existing client configurations and will therefore be able to take over if the main server fails. Rentschler Expires April 2004 [Page = 1] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 Requirements terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. Introduction Host Configuration using "traditional" DHCP according to RFC 2131 is based on host- (client-) initiated communication. If a network is booting, all the clients start sending DHCP requests until=20 accepting an answer from a DHCP server. The server may either allocate IP addresses out of a pool of=20 available adresses or, similar to BOOTP, pre-configured static IP addresses and configuration parameters for each known client. These concepts did not intend server-initiated and -controlled configuration or reconfiguration of clients. This capability was later partially added with RFC 3203, but the mechanism there does not allow to discover "silent" clients yet unknown to the server=20 or trigger the configuration of such a client. =20 =20 These shortcomings will be overcome with the protocol extensions=20 described in this document, which will provide useful functionality for centralized network administration: - scanning the network for clients even prior to their=20 initialization with IP parameters. Building a database of all=20 clients present in a network.=20 - detecting and identifying duplicate network addresses - administrator controlled reconfiguration of certain clients=20 - server redundancy mechanism The main goal of the discovery extension is to allow as much flexibility as possible for the server to communicate with the client(s).=20 The DHCP discovery extensions may also be adopted for DHCPv6. Rentschler Expires April 2004 [Page = 2] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 2. The DHCP Discovery Protocol One of the intentions of the DHCP Discovery Protocol Extension is to work with an inactive DHCP client (the client is not sending=20 initial DHCPDISCOVER messages) to allow the configuration process=20 be entirely performed and controlled by the administrator's management station.=20 The DHCP Discovery Protocol MUST also work with an active client (the client is sending initial DHCPDISCOVER messages). This server-initiated communication mechanism has basically the following modes of operation: The server sends the new DHCPNETSCAN message into the network,=20 either as broadcast to all clients or directed to a certain client.=20 The client responds with the new DHCPREPORT message containing=20 the client's actual parameter settings. All servers that receive=20 the DHCPREPORT message SHOULD use the information contained in=20 this message to maintain their internal database (list of clients=20 and leases).=20 With this mechanism all available DHCP servers in the network=20 can collect information about granted leases and can take over in=20 the normal rebinding process if the granting server fails. For the configuration of a certain client the server sends the=20 new DHCPCONFIGURE message to this client that MUST contains all parameters required to set the client's IP stack in operation.=20 The client responds with a DHCPREPORT message back to the=20 server(s) to indicate if it accepted the new=20 configuration parameters. The DHCP client MUST maintain its=20 internal database and MUST release an already existing lease by sending a DHCPRELEASE message, if it accepted new IP settings. =20 The server that has granted a lease MUST be able to renew and rebind that lease. All other servers that have sufficient information about that lease in their database MAY rebind it as well to provide server = redundancy. Rentschler Expires April 2004 [Page = 3] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 3. New DHCP message types Three messages MUST be added to the set of existing DHCP messages: DHCPNETSCAN DHCPCONFIGURE DHCPREPORT The value of the message types -to be encoded in DHCP option 53- is left as TBD until assigned by IANA. Existing correct implementations of DHCP clients or servers SHOULD ignore and discard these new message types. =20 =20 To existing correct implementations of BOOTP relay agents these new message types SHOULD be transparent. 3.1 DHCPNETSCAN message The DHCPNETSCAN message is sent from a server to one client (unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay agent's other subnets.=20 Its purpose is to request the client's actual parameter settings=20 and report them to the server(s) by triggering a DHCPREPORT message. Field Contents ----- ------------=20 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server=20 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address=20 'yiaddr' 0 'siaddr' IP address of server 'giaddr' 0 or the target relay agent's interface IP adress 'chaddr' 0 or client's hardware address 'sname' unused 'file' unused 'options' 53: DHCP Message Type: DHCPNETSCAN 54: Server Identifier 55: Parameter Request List=20 (MUST: 1 =3D Subnet Mask, 3 =3D Router) 82: Relay port identification (MAY) Rentschler Expires April 2004 [Page = 4] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 3.2 DHCPCONFIGURE message The DHCPCONFIGURE message is sent from a server to a client=20 Its purpose is to provide the client with new parameter settings.=20 Field Contents ----- ------------=20 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server=20 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address=20 'yiaddr' IP address for client 'siaddr' IP address of server 'giaddr' 0 =20 'chaddr' 0 or client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 01: Subnet Mask 03: Router 51: IP address lease time 53: DHCP Message Type: DHCPCONFIGURE 54: Server Identifier 55: Parameter Request List=20 (MUST: 1 =3D Subnet Mask, 3 =3D Router) additional any other options, which must then also be present in the parameter request list.=09 82: Relay Agent Information (MAY) Rentschler Expires April 2004 [Page = 5] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 3.3 DHCPREPORT message The purpose of this message is to report the client's actual=20 parameter settings to one or all servers. The DHCPREPORT message is sent from a client to a server as broadcast or unicast, depending on the 'BROADCAST' flag in the original DHCPNETSCAN or DHCPCONFIGURE message and the state of the client's IP stack. A client that has not yet assigned a=20 valid IP address SHOULD always broadcast this message,=20 using 0.0.0.0 as source address and the limited broadcast=20 address 255.255.255.255 as destination address. Field Contents ----- ------------=20 'op' BOOTREQUEST (RFC 2131: client to server direction) 'xid' 'xid' from server=20 'secs' 0 or seconds since DHCP process started 'flags' flags from DHCPNETSCAN or DHCPNETCONIFG message 'ciaddr' 0 or client's network address=20 'yiaddr' IP address of client 'siaddr' 0=20 'giaddr' 0 =20 'chaddr' client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 01: Subnet Mask 03: Router 51: IP address lease time 53: DHCP Message Type: DHCPREPORT 54: Server Identifier 57: Maximum DHCP Message Size 61: Client identifier additional all supported options requested=20 in DHCPNETSCAN or DHCPCONFIGURE. Rentschler Expires April 2004 [Page = 6] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 4. The DHCP Server DHCP Server implementations MAY incorporate any administrative=20 conrols or policies desired by network administrators that make use of the underlying protocol described in this and related documents. DHCP servers that support the protocol described in this document MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages,=20 either automatically at startup, program controlled, in certain intervals and/or on manual requests.=20 The content of the BROADCAST flag in the DHCPNETSCAN and DHCPCONFIGURE messages SHOULD be configurable and set to BROADCAST by default. The DHCP server MUST be able to receive DHCPREPORT messages and=20 SHOULD use them to verify the state of pending requests.=20 The 'xid' field SHOULD be used by the server to match incoming DHCP=20 messages with pending requests.=20 Pending requests SHOULD be supervised using a timeout mechanism.=20 The timeout value MUST be configurable and SHOULD have a default value of 4 seconds.=20 A retransmission strategy for unacknowledged requests MAY be=20 implemented. The server MAY use all received DHCPREPORT messages to build and maintain an internal database (based on IP addresses), that MAY=20 contain all known leases in the network. This database MAY be=20 periodically updated by sending DHCPNETSCAN messages.=20 If a server receives a DHCPREPORT message for a lease that was=20 granted by itself, the contents MUST be checked for consistency with the internal lease database.=20 If any inconsistency is detected (i.e. unknown MAC address or=20 wrong relay agent information option contents), these DHCPREPORTS MUST be ignored and their occurence MUST be reported to the=20 administrator. It is RECOMMENDED that a timeout mechanism removes expired leases=20 in this database. The server MUST be able to renew and rebind existing leases which were granted by itself. The server MAY be able to rebind existing leases which were not=20 granted by itself, but are listed in its internal database as known leases. This feature should be configurable and enabled by default. If duplicate IP addresses are detected in the database, the server SHOULD report this to the administrator. If duplicate client identifiers (DHCP Option 61) are detected in the database, the server MAY report this to the administrator. Rentschler Expires April 2004 [Page = 7] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 5. The DHCP Client The DHCP client needs to be modified to incorporate the handling of=20 the new message types. The clients network interface MUST always be able to receive BOOTREPLY packets on its UDP client port (68), even if the local IP stack has not yet assigned a valid IP address. DHCPNETSCAN and DHCPCONFIGURE messages MUST always be processed, even if the local DHCP client is not active in terms of sending=20 initial DHCPDISCOVER messages.=20 It SHOULD be configurable whether a client is allowed to accept=20 reconfiguration due to receipt of a DHCPCONFIGURE message from=20 another than the initially granting server.=20 This feature SHOULD be disabled by default. The client MUST respond to a DHCPNETSCAN or DHCPCONFIGURE message with the message DHCPREPORT and return the requested parameters to the server. The Message DHCPREPORT contains always the client's current=20 parameter settings. The client MUST omit any parameters it cannot provide. The sending of a broadcast DHCPREPORT message that was generated in response to a DHCPNETSCAN message SHOULD be delayed a random time interval up to 2 seconds to prevent broadcast storms on the network. DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently discarded and not queued for processing. =20 The client's handling of a received DHCPNETSCAN message SHOULD be the same in every state of the DHCP client's state machine. It = SHOULD not affect the current state of the client's state machine.=20 The receipt of a DHCPCONFIGURE message MUST result in the following actions: If the message and the parameters offered to the client are correct and acceptance of DHCPCNFIGURE is not disabled, the new parameters MUST be accepted. An existing lease MUST be terminated by sending a DHCPRELEASE message. Then the client's IP stack is=20 initialized with the new parameters and the client sends a=20 DHCPREPORT to the server, containing the new parameter settings. Then the DHCP client's state machine always enters the state BOUND and starts its timers T1 and T2 for the renewing/rebinding process. If any DHCP message received by the client contains a relay agent=20 information option, this field MAY be examined for informational=20 purposes. Rentschler Expires April 2004 [Page = 8] =0C Internet-Draft DHCP Discovery Extensions Oct 2003= 6. The BOOTP Relay Agent =20 DHCPNETSCAN messages that are received as IP broadcast on one of the relay's interfaces MUST be broadcasted in all other IP subnets accessible by this relay agent.=20 This option SHOULD be configurable and disabled by default.=20 DHCPNETSCAN messages that are received as IP unicast directed to=20 one of the relay agent's IP interfaces and have the giaddr field set to the same interface address MUST be broadcasted only on the physical ports attached to this IP interface. This allows scanning of a specified subnet. This option SHOULD be configurable and disabled by default.=20 If one of the above packets -directed to the client- has the relay agent information option present, this field SHOULD be examined. If the contents of the Agent Remote ID matches the relay agent's unique identifier (i.e. MAC, Client-Id or an IP address) AND the=20 Agent Circuit ID suboption contains a valid physical port number, this information SHOULD be used to forward the DHCPNETSCAN=20 message to the client.=20 Rentschler Expires April 2004 [Page = 9] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 7. Security Considerations In this section possible security attacks and prevention=20 mechanisms will be discussed. - Denial of Service attacks through DHCPNETSCAN A bogus server may flood the network with broadcast DHCPNETSCAN messages at such a rate, that due to multiple client responses=20 other communication will slow down. In order to keep damage low in case of such an attack, the client delays the generation of the DHCPREPORT message and discards=20 DHCPNETSCAN messages that were received in the meantime. - Denial of Service attacks through DHCPCONFIGURE A bogus server may send DHCPCONFIGURE packets to misconfigure=20 clients in the network. To prevent this the client incorporates a configurable mechanism that only allows reconfiguration by the=20 initially granting server. - Denial of Service attacks through DHCPREPORT A bogus client may send DHCPREPORT packets into the network to misinform servers about existing leases in the network.=20 A server that has granted a lease needs to check incoming=20 DHCPREPORTS concerning this lease for consistency. 8. IANA Considerations The value for the new message types=20 =20 DHCPNETSCAN DHCPCONFIGURE DHCPREPORT must be assigned from the numbering space defined for message types in RFC 2939. Rentschler Expires April 2004 [Page = 10] =0C Internet-Draft DHCP Discovery Extensions Oct = 2003 9. References RFC 1542 W. Wimer, October 1993, "Clarifications/Extensions for the Bootstrap Protocol", RFC 2131 R. Droms, March 1997,=20 "The Dynamic Host Configuration Protocol",=20 RFC 2939 R. Droms, September 2000,=20 "Procedures an IANA guidelines for Definition of new DHCP Options and Message Types",=20 RFC 3046, M. Patrick, January 2001,=20 "DHCP Relay Agent Information Option",=20 RFC 2131 R. Droms and W. Arbaugh, June 2001,=20 "Authentication for DHCP Messages", RFC 3203, Y. T'Joens et. al., December 2001,=20 "DHCP reconfigure extension",=20 10. Acknowledgments We Acknowledge the help of .... and all the members of the development department at Hirschmann Electronics GmbH & Co. KG. 11. Author's Address Markus Rentschler Hirschmann Electronics GmbH & Co. KG, Neckartenzlingen, Germany. Email: mrentsch@nt.hirschmann.de Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Rentschler Expires April 2004 [Page = 11] ------_=_NextPart_000_01C3A1F7.0C32B670 Content-Type: text/plain; name="draft-rentschler-dhc-interface-opt-00.txt" Content-Disposition: attachment; filename="draft-rentschler-dhc-interface-opt-00.txt" Content-Transfer-Encoding: quoted-printable DHC Markus Rentschler Internet Draft Hirschmann Electronics = =20 Expires: April 2004 November 2003 DHCP Interface Information Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft defines a new option to inform the server about the client's physical interface it is connected to. This information may be used together with the relay agent=20 information option (RFC 3046) for the purpose of topology=20 recognition. Requirements terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Rentschler Expires April 2004 [Page = 1] =0C Internet-Draft DHCP Interface Information Option Oct = 2003 1. Introduction The relay agent information option [RFC 3046], which is added by a relay agent to a client's request to the server, contains in its Circuit ID sub option the number of the physical interface on which the relay received this client's request. When the client itself is a device with multiple interfaces=20 (for example a Switching Hub), it would be of interest to know which of the client's interfaces is connected to the relay agent or the=20 server. These informations together could then easily be used to=20 detect and display the active topology of the underlying network. To get the information about the client's physical interface to the server, a new option has to be introduced. 2. Interface Information Option=20 The Interface Information Option encodes a client-local identifier (such as a Switching Hub port number) of the interface from which the initial DHCP server-to-client packet was received. This option MAY be added by DHCP clients.=20 =20 Opt Len Interface Information +------+------+------+------+------+------+------+------+-- | TBD | n | c1 | c2 | c3 | c4 | c5 | c6 | ... +------+------+------+------+------+------+------+------+-- The DHCP server SHOULD report the Interface Information Option of current leases in statistical reports, its MIB and in logs. Since the Interface Information Option is local only to a particular client, the Interface Information Option should be qualified with=20 the MAC or IP address that identifies the client. Servers MAY use the Interface Information Option for IP and other=20 parameter assignment policies. Rentschler Expires April 2004 [Page = 2] =0C Internet-Draft DHCP Interface Information Option Oct = 2003 3. Description of Operation When the client receives a DHCP message from a server=20 (i.e. DHCPOFFER) which requests in its paramter request list the new Interface Information Option, the client SHOULD append the new Interface Information Option on the responding message to the server (i.e. DHCPREQUEST). 4. Security Considerations This document does not cover possible security attacks. 5. IANA Considerations The value for the new Interfce Information Option must be assigned from the numbering space defined for DHCP options in RFC 2939. 6. References RFC 2131 R. Droms, March 1997,=20 "The Dynamic Host Configuration Protocol",=20 RFC 2132 S.Alexander, R. Droms, March 1997,=20 "DHCP Options and BOOTP vendor Extensions" RFC 2939 R. Droms, September 2000,=20 "Procedures an IANA guidelines for Definition of new DHCP Options and Message Types",=20 RFC 3046, M. Patrick, January 2001,=20 "DHCP Relay Agent Information Option",=20 Rentschler Expires April 2004 [Page = 3] =0C Internet-Draft DHCP Interface Information Option Oct = 2003 7. Author's Address Markus Rentschler Hirschmann Electronics GmbH & Co. KG, Neckartenzlingen, Germany. Email: mrentsch@nt.hirschmann.de Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Rentschler Expires April 2004 [Page 4] ------_=_NextPart_000_01C3A1F7.0C32B670-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 3 17:24:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28403; Mon, 3 Nov 2003 17:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn7B-0004LS-OB; Mon, 03 Nov 2003 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGdoO-0001kl-KT for dhcwg@optimus.ietf.org; Mon, 03 Nov 2003 07:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29204; Mon, 3 Nov 2003 07:27:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGdoO-0004ci-00; Mon, 03 Nov 2003 07:28:00 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGdoN-0004cX-00; Mon, 03 Nov 2003 07:27:59 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3CRRZ31436; Mon, 3 Nov 2003 14:27:27 +0200 Date: Mon, 3 Nov 2003 14:27:26 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: dhcwg@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 30 Oct 2003, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following document: > > - 'A Guide to Implementing Stateless DHCPv6 Service' > as a Proposed Standard Comments below. The document needs a revision, but does not have, AFAICS, major issues to deal with, except for better considerations on how DHCP relays work (or don't :-) in the stateless/full DHCP model.. that is, do you have "stateless relays" and "full relays", and potential problems to stateful services stemming from that or not. Note: IMHO, DHCP spec should have been the other way around, stateless first, adding stateful parts on top of that as an extension. Can't be changed now, but might be something to consider when going to Draft Standard or the like. substantial ----------- 1) the spec is not sufficiently clear how the relays behave in a mixed world of stateless/stateful DHCP service. That is, would deploying a stateless-only relay (if such a thing is possible?) harm the stateful DHCP clients? Is the implementation of a relay any different for full/stateless DHCP service, etc. ?: The operation of relay agents is the same for stateless and stateful DHCPv6 service. The operation of relay agents is described in the DHCPv6 specification. 2) there are a few remnants on the spec which talk about "DNS configuration parameters". One should be more generic than that; these are listed in the editorials section. 3) I'm not familiar with DHCPv6 spec, but I'd like a confirmation that the last sentence is actually true, and to reword it for clarity if so: A DHCP server that is only able to provide stateless configuration information through an Information-request/Reply message exchange discards any other DHCP messages it receives. Specifically, the server discards any messages other than Information-Request or Relay-forward it receives, and the server does not participate in any stateful address configuration messages exchanges. If there are other DHCP servers that are configured to provide stateful address assignment, one of those servers will provide the address assignment. ==> that is, do relays really *flood* these messages to all the DHCPv6 servers they know, so that if one doesn't process the request but silently ignores it, the others can step up and handle the job? See also the point 1) above. editorial --------- the node's message with a Reply message that carries the DNS configuration parameters. The Reply message from the server can ==> s/DNS// 1-4: give an introduction to DHCPv6 and an overview of DHCP message flows ==> some of those flows are redundant to Stateless DHCPv6 operation, though.. :-) 5. Implementation of stateless DHCP ==> s/stateless/Stateless/ DNS configuration information, it includes either or both of the DNS configuration options in the Information-request message. ==> one should list here the two kinds of DNS config options, or reword the sentence. 5.1 Messages required for stateless DHCP ==> s/r/R/, s/s/S/ Clients and servers implement the following messages for stateless DHCP service; the section numbers in this list refer to the DHCPv6 specification: ==> many sections are missing the "the section ..." blurb. It might make sense to add something at the end of section 5, like, "In the following subsections, the section numbers used refer to the DHCPv6 specification". Information-request: sent by a DHCP client to a server to request DNS configuration parameters (sections 18.1.5 and 18.2.5) Reply: sent by a DHCP server to a client containing the DNS configuration parameters (sections 18.2.6 and 18.2.8) ==> s/DNS// (2 cases) 5.2 Options required for stateless DHCP service ==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other 5.x) 5.3 Options used for configuration information ==> s/u/U/, s/c/C/, s/i/I/ 5.4 Other options used in stateless DHCP ==> s/o/O/, s/u/U/, s/s/S/ DHCP service; the section numbers in this list refer to the DHCPv6 specification, RFC 3315>: ==> see above, but if keeping it here, make consistent with the rest 22.2). Clients are not required to send this option; servers send the option back if included in a message fro ma client ==> s/fro ma/from a/ -- 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-admin@ietf.org Mon Nov 3 17:32:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29166; Mon, 3 Nov 2003 17:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnEv-0005RN-7q; Mon, 03 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnEp-0005Qx-KH for dhcwg@optimus.ietf.org; Mon, 03 Nov 2003 17:31:55 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29109 for ; Mon, 3 Nov 2003 17:31:43 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AGmym-0007hr-P8; Mon, 03 Nov 2003 17:15:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 03 Nov 2003 17:15:20 -0500 Subject: [dhcwg] Document Action: 'Unused DHCP Option Codes' to Informational RFC Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'Unused DHCP Option Codes ' 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 3 18:16:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02786; Mon, 3 Nov 2003 18:16:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnvW-0000hv-JM; Mon, 03 Nov 2003 18:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnvD-0000ha-UW for dhcwg@optimus.ietf.org; Mon, 03 Nov 2003 18:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02675 for ; Mon, 3 Nov 2003 18:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnvA-0000Io-00 for dhcwg@ietf.org; Mon, 03 Nov 2003 18:15:40 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AGnv9-0000HW-00 for dhcwg@ietf.org; Mon, 03 Nov 2003 18:15:39 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AGnuT-0000dM-00; Mon, 03 Nov 2003 15:14:57 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5WW9T>; Mon, 3 Nov 2003 15:14:33 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface Informati on Option Date: Mon, 3 Nov 2003 15:14:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A260.3DC5A8F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A260.3DC5A8F0 Content-Type: text/plain; charset="iso-8859-1" Regarding: DHCP Interface Information Option - According to RFC 2131, a DHCP Server MUST NOT supply a Parameter Request List option to a client (in OFFER, ACK, or NAK), thus a server cannot request this option. Regarding: DHCP Discovery Extensions - I think there's some overlap here. What's different between a DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) (Functionally speaking). Both of them cause a device to acquire new configuration information. - The DHCP Client behaviour talks about an "initially granting server", what if the device has not yet been granted a lease from any server? - I don't think this draft really takes into consideration the scope of where DHCP is used. According to the draft, a DHCPNETSCAN may be broadcast, and should be relayed onto all other subnets. Thus if a central DHCP server emits 1 of these messages, that will result in it being broadcast to _everything_ on an entire intranet. And what about relays behind relays? What about relays that aren't on the same subnet as the originating server? And then there's the problem of potentially hundreds of thousands of devices _all_ trying to DHCPREPORT back to the server within a 2 second timeframe! - DHCPREPORT says that option 61 is to be supplied. There is no requirement that a client _has_ a clientID. It also says that option 3 is to be supplied too. A device may not have a router defined. - DHCPCONFIGURE is very disruptive to the network. If all the administrator changed was the client's DNS settings (for example), this draft requires the client to RELEASE it's existing lease, and then assume the new settings. It's a little foggy as to what the DHCP server is going to do when it receives this RELEASE message. The draft also doesn't specify what order the RELEASE and REPORT are to be sent in. - In section 3 you state: "To existing correct implementations of BOOTP relay agents these new message types SHOULD be transparent." This is incorrect. For DHCPNETSCAN (A server-to-client message), the bootp relay agent is supposed to broadcast that message on all connected subnets (except the one it was received on). This is not the "normal" behaviour of a relay agent. In the abstact these are the stated goals: - Discovery of clients in the network - DHCP server redundancy - Server-initiated configuration of clients DHCP server redundancy is already covered in the Failover draft. Server-initiated configuration is covered in RFC 3203. I'm not sure that this draft can even do the Discovery of clients in the network, as any device which doesn't perform DHCP would be completely invisible to this scheme (as would any device which doesn't implement this draft). Also in your references list, you list RFC 2131 as Authentication for DHCP Messages. That's RFC 3118. Also, you make no actual reference to DHCP Authentication within your draft. BTW: Does this draft have implications for the zeroconf people? > -----Original Message----- > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de] > Sent: Monday, November 03, 2003 2:42 AM > To: dhcwg@ietf.org > Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface > Information > Option > > > Hello DHC-WG, > > I seem to have missed the deadline for ID submission, but need some > criticism/feedback on the issues described in the enclosed > drafts. Please > read through the documents and let me know your comments. > > The abstracts of these drafts are given here: > > -- DHCP Discovery Extensions -- > > This draft defines simple protocol enhancements to DHCP so that it > can be used for the following applications: > > - Discovery of clients in the network > - DHCP server redundancy > - Server-initiated configuration of clients > > The discovery mechanism described here is built upon and coexists > with BOOTP according to RFC 1542 and DHCP according to RFC 2131 > and RFC 3203. > It allows server-initiated communication to specific or > all clients > in the network, using the DHCP packet format. Other DHCP servers > in the network can be provided with information about all > existing client configurations and will therefore be able to take > over if the main server fails. > > <> > > > > -- DHCP Interface Information Option -- > > This draft defines a new option to inform the server about > the client's physical interface it is connected to. > This information may be used together with the relay agent > information option (RFC 3046) for the purpose of topology > recognition. > > <> > > > > Best Regards, > Markus Rentschler > > > ------_=_NextPart_001_01C3A260.3DC5A8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface = Information Option

Regarding: DHCP Interface Information Option

- According to RFC 2131, a DHCP Server MUST NOT = supply a Parameter Request List option to a client (in OFFER, ACK, or = NAK), thus a server cannot request this option.


Regarding: DHCP Discovery Extensions

- I think there's some overlap here.  What's = different between a DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) = (Functionally speaking).  Both of them cause a device to acquire = new configuration information.

- The DHCP Client behaviour talks about an = "initially granting server", what if the device has not yet = been granted a lease from any server?

- I don't think this draft really takes into = consideration the scope of where DHCP is used.  According to the = draft, a DHCPNETSCAN may be broadcast, and should be relayed onto all = other subnets.  Thus if a central DHCP server emits 1 of these = messages, that will result in it being broadcast to _everything_ on an = entire intranet.  And what about relays behind relays?  What = about relays that aren't on the same subnet as the originating = server?  And then there's the problem of potentially hundreds of = thousands of devices _all_ trying to DHCPREPORT back to the server = within a 2 second timeframe!

- DHCPREPORT says that option 61 is to be = supplied.  There is no requirement that a client _has_ a = clientID.  It also says that option 3 is to be supplied too.  = A device may not have a router defined.

- DHCPCONFIGURE is very disruptive to the = network.  If all the administrator changed was the client's DNS = settings (for example), this draft requires the client to RELEASE it's = existing lease, and then assume the new settings.  It's a little = foggy as to what the DHCP server is going to do when it receives this = RELEASE message.  The draft also doesn't specify what order the = RELEASE and REPORT are to be sent in.

- In section 3 you state: "To existing correct = implementations of BOOTP relay agents these new message types SHOULD be = transparent."  This is incorrect.  For DHCPNETSCAN (A = server-to-client message), the bootp relay agent is supposed to = broadcast that message on all connected subnets (except the one it was = received on).  This is not the "normal" behaviour of a = relay agent.

In the abstact these are the stated goals:

   - Discovery of clients in the = network
   - DHCP server redundancy
   - Server-initiated configuration of = clients

DHCP server redundancy is already covered in the = Failover draft.  Server-initiated configuration is covered in RFC = 3203.  I'm not sure that this draft can even do the Discovery of = clients in the network, as any device which doesn't perform DHCP would = be completely invisible to this scheme (as would any device which = doesn't implement this draft).

Also in your references list, you list RFC 2131 as = Authentication for DHCP Messages.  That's RFC 3118.  Also, = you make no actual reference to DHCP Authentication within your = draft.


BTW: Does this draft have implications for the = zeroconf people?

> -----Original Message-----
> From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.= de]
> Sent: Monday, November 03, 2003 2:42 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] ID's: DHCP Discovery = Extensions / Interface
> Information
> Option
>
>
> Hello DHC-WG,
>
> I seem to have missed the deadline for ID = submission, but need some
> criticism/feedback on the issues described in = the enclosed
> drafts. Please
> read through the documents and let me know your = comments.
>
> The abstracts of these drafts are given = here:
>
> -- DHCP Discovery Extensions --
>
>    This draft defines simple = protocol enhancements to DHCP so that it
>    can be used for the following = applications:
>
>    - Discovery of clients in the = network
>    - DHCP server = redundancy
>    - Server-initiated = configuration of clients
>
>    The discovery mechanism = described here is built upon and coexists
>    with BOOTP according to RFC = 1542 and DHCP according to RFC 2131
>    and RFC 3203.
>    It allows server-initiated = communication to specific or
> all clients
>    in the network, using the = DHCP packet format. Other DHCP servers
>    in the network can be = provided with information about all
>    existing client = configurations and will therefore be able to take
>    over if the main server = fails.
>
>  = <<draft-rentschler-dhc-discovery-00.txt>>
>
>
>
> -- DHCP Interface Information Option --
>
>    This draft defines a new = option to inform the server about
>    the client's physical = interface it is connected to.
>    This information may be used = together with the relay agent
>    information option (RFC 3046) = for the purpose of topology
>    recognition.
>
>  = <<draft-rentschler-dhc-interface-opt-00.txt>>
>
>
>
> Best Regards,
>          = ;  Markus Rentschler
>
>
>

------_=_NextPart_001_01C3A260.3DC5A8F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 02:53:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02581; Tue, 4 Nov 2003 02:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvzp-0004YR-TY; Tue, 04 Nov 2003 02:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvzH-0004Vn-HG for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 02:52:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02551 for ; Tue, 4 Nov 2003 02:52:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvzD-0000GS-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 02:52:23 -0500 Received: from mail.hirschmann.ch ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AGvzC-0000G1-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 02:52:22 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119046>; Tue, 4 Nov 2003 08:44:51 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Nov 2003 08:48:47 +0100 Message-ID: From: "Rentschler, Markus" To: "Kostur, Andre" , dhcwg@ietf.org Subject: AW: [dhcwg] ID's: Interface Information Option Date: Tue, 4 Nov 2003 08:48:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Andre, [MR>] Im going to split my answers by subject... -----Urspr=FCngliche Nachricht----- Von: Kostur, Andre [SMTP:Andre@incognito.com] Gesendet am: Dienstag, 4. November 2003 00:15 An: 'Rentschler, Markus'; dhcwg@ietf.org Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface Informati on Option Regarding: DHCP Interface Information Option=20 - According to RFC 2131, a DHCP Server MUST NOT supply a Parameter Request List option to a client (in OFFER, ACK, or NAK), thus a server cannot request this option. [MR>] Ok. Then a client that has multiple interfaces SHOULD always send the Interface Information Option to the server, without any = request. That wouldn't violate the restriction you've mentioned. Apart from that: I cannot see any useful reason for that restriction, since it limits the potential of DHCP. Any idea what might be the background of that restriction ? Markus > > -----Original Message-----=20 > > From: Rentschler, Markus [ ]=20 > > Sent: Monday, November 03, 2003 2:42 AM=20 > > To: dhcwg@ietf.org=20 > > Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface=20 > > Information=20 > > Option=20 > >=20 > >=20 > > Hello DHC-WG,=20 > >=20 > > I seem to have missed the deadline for ID submission, but need some = > > criticism/feedback on the issues described in the enclosed=20 > > drafts. Please=20 > > read through the documents and let me know your comments.=20 > >=20 > > The abstracts of these drafts are given here:=20 > >=20 > > -- DHCP Discovery Extensions --=20 > >=20 > > This draft defines simple protocol enhancements to DHCP so that = it=20 > > can be used for the following applications:=20 > >=20 > > - Discovery of clients in the network=20 > > - DHCP server redundancy=20 > > - Server-initiated configuration of clients=20 > >=20 > > The discovery mechanism described here is built upon and = coexists=20 > > with BOOTP according to RFC 1542 and DHCP according to RFC 2131=20 > > and RFC 3203.=20 > > It allows server-initiated communication to specific or=20 > > all clients=20 > > in the network, using the DHCP packet format. Other DHCP servers = > > in the network can be provided with information about all=20 > > existing client configurations and will therefore be able to = take=20 > > over if the main server fails.=20 > >=20 > > <>=20 > >=20 > >=20 > >=20 > > -- DHCP Interface Information Option --=20 > >=20 > > This draft defines a new option to inform the server about=20 > > the client's physical interface it is connected to.=20 > > This information may be used together with the relay agent=20 > > information option (RFC 3046) for the purpose of topology=20 > > recognition.=20 > >=20 > > <>=20 > >=20 > >=20 > >=20 > > Best Regards,=20 > > Markus Rentschler=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 04:33:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05559; Tue, 4 Nov 2003 04:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxYa-0004Df-V9; Tue, 04 Nov 2003 04:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxYG-0004BS-7f for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 04:32:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05540 for ; Tue, 4 Nov 2003 04:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxYD-0001ip-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 04:32:37 -0500 Received: from mail.hirschmann.ch ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AGxYC-0001if-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 04:32:36 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119044>; Tue, 4 Nov 2003 10:25:02 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Nov 2003 10:28:59 +0100 Message-ID: From: "Rentschler, Markus" To: "Kostur, Andre" , dhcwg@ietf.org Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions Date: Tue, 4 Nov 2003 10:28:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Andre, > -----Urspr=FCngliche Nachricht----- > Von: Kostur, Andre [SMTP:Andre@incognito.com] > Gesendet am: Dienstag, 4. November 2003 00:15 > An: 'Rentschler, Markus'; dhcwg@ietf.org > Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface > Informati on Option >=20 ....=20 > Regarding: DHCP Discovery Extensions=20 >=20 > - I think there's some overlap here. What's different between a > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) (Functionally = speaking). > Both of them cause a device to acquire new configuration information. [MR>] =20 To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must already have a lease assigned! With the Discovery Extensions I try to overcome this.=20 It's in fact a different philosophy to "traditional" DHCP, even a different protocol, that just uses the DHCP packet format and the DHCP infrastructure!! This point must be clearly understood. Right now there are some proprietary Discovery Protocols under development by some industry consortiums that go into that direction. But I don't want yet another proprietary packet format and protocol infrastructure if I can easily adopt DHCP, which does familiar things anyway. Thats the background of my draft. > - The DHCP Client behaviour talks about an "initially granting = server", > what if the device has not yet been granted a lease from any server? [MR>] See my point above. In that case it is configuration, not reconfiguration!=20 Reconfiguration should be restricted to the initially granting server, but not configuration. > - I don't think this draft really takes into consideration the scope = of > where DHCP is used. According to the draft, a DHCPNETSCAN may be > broadcast, and should be relayed onto all other subnets. Thus if a > central DHCP server emits 1 of these messages, that will result in it > being broadcast to _everything_ on an entire intranet. And what = about > relays behind relays? What about relays that aren't on the same = subnet as > the originating server? And then there's the problem of potentially > hundreds of thousands of devices _all_ trying to DHCPREPORT back to = the > server within a 2 second timeframe! [MR>] For this reason I propose to make this mechanism (Broadcasting over relays) configurable. Then it's entirely in the responsibility of the network administrator, if he wants to take the potential risk having his network flooded with broadcasts.I see the application of the discovery mechanism mainly in networks that run on factory floors, which are not publicly accessible and consist of lets = say a maximum of ten thousand devices. I also proposed in my draft to restrict broadcasting to certain relay interfaces, using the giaddr-field and/or the relay agent = information option. I think this would be very useful for security reasons and scalability (the server will be able to scan subnet for subnet or = interface for interface) > - DHCPREPORT says that option 61 is to be supplied. There is no > requirement that a client _has_ a clientID. It also says that option = 3 is > to be supplied too. A device may not have a router defined. [MR>] "The client MUST omit any parameters it cannot provide." (see chapter 5). This should of course also be mentioned in chapter 3.3. > - DHCPCONFIGURE is very disruptive to the network. If all the > administrator changed was the client's DNS settings (for example), = this > draft requires the client to RELEASE it's existing lease, and then = assume > the new settings.=20 [MR>] The Discovery Extensions rely heavily on the server. The people that implement and/or operate the server need to know what they = are doing. Of course can misuse of he server disrupt the network. I can' t = see any other strategy to prevent that than firing the admin if he misuses = the server under his control ;-)). > It's a little foggy as to what the DHCP server is going to do when = it > receives this RELEASE message. =20 [MR>] Standard RFC2131 behaviour: The server has to check its internal lease database and relase that lease.=20 Sending a RELEASE is mainly for backward compatibility with RFC 2131 if there is a server on the network that doesn't support the discovery extensions. > The draft also doesn't specify what order the RELEASE and REPORT are = to be > sent in. [MR>] First RELEASE then REPORT. > - In section 3 you state: "To existing correct implementations of = BOOTP > relay agents these new message types SHOULD be transparent." This is > incorrect. For DHCPNETSCAN (A server-to-client message), the bootp = relay > agent is supposed to broadcast that message on all connected subnets > (except the one it was received on). This is not the "normal" = behaviour > of a relay agent. [MR>] This describes the desired extended behaviour defined in my draft. An existing relay agent that does not support the discovery = extension should never broadcast the DHCPNETSCAN packet.=20 > In the abstact these are the stated goals:=20 > - Discovery of clients in the network=20 > - DHCP server redundancy=20 > - Server-initiated configuration of clients=20 >=20 > DHCP server redundancy is already covered in the Failover draft. [MR>] This is true. But server redundancy is not the main purpose of the discovery extension. It's a nice "side-effect" and IMHO much = less complicated than the failover protocol. But server redundancy only = works with clients that are able to broadcast DHCPREPORT messages. It will = not work with old BOOTP and DHCP clients, since they are unable to tell = other servers about their configuration. > Server-initiated configuration is covered in RFC 3203. I'm not = sure > that this draft can even do the Discovery of clients in the network, = as > any device which doesn't perform DHCP would be completely invisible = to > this scheme (as would any device which doesn't implement this draft). [MR>] For not beeing invisible, a device needs at least to be capable of BOOTP or DHCP, since they tell the server "Hey, I'm here!". = For silent discovery, the clients of course need to be capable of the = Discovery Extensions. > Also in your references list, you list RFC 2131 as Authentication for = DHCP > Messages. That's RFC 3118.=20 [MR>] Thanks for hinting that mistake. It will be corrected. > Also, you make no actual reference to DHCP Authentication within your > draft. [MR>] I haven't yet thougt much about that. =20 > BTW: Does this draft have implications for the zeroconf people?=20 [MR>] I think It might go somehow into their direction. Best Regards, Markus =20 > > -----Original Message-----=20 > > From: Rentschler, Markus [ ]=20 > > Sent: Monday, November 03, 2003 2:42 AM=20 > > To: dhcwg@ietf.org=20 > > Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface=20 > > Information=20 > > Option=20 > >=20 > >=20 > > Hello DHC-WG,=20 > >=20 > > I seem to have missed the deadline for ID submission, but need some = > > criticism/feedback on the issues described in the enclosed=20 > > drafts. Please=20 > > read through the documents and let me know your comments.=20 > >=20 > > The abstracts of these drafts are given here:=20 > >=20 > > -- DHCP Discovery Extensions --=20 > >=20 > > This draft defines simple protocol enhancements to DHCP so that = it=20 > > can be used for the following applications:=20 > >=20 > > - Discovery of clients in the network=20 > > - DHCP server redundancy=20 > > - Server-initiated configuration of clients=20 > >=20 > > The discovery mechanism described here is built upon and = coexists=20 > > with BOOTP according to RFC 1542 and DHCP according to RFC 2131=20 > > and RFC 3203.=20 > > It allows server-initiated communication to specific or=20 > > all clients=20 > > in the network, using the DHCP packet format. Other DHCP servers = > > in the network can be provided with information about all=20 > > existing client configurations and will therefore be able to = take=20 > > over if the main server fails.=20 > >=20 > > <>=20 > >=20 > >=20 > >=20 > > -- DHCP Interface Information Option --=20 > >=20 > > This draft defines a new option to inform the server about=20 > > the client's physical interface it is connected to.=20 > > This information may be used together with the relay agent=20 > > information option (RFC 3046) for the purpose of topology=20 > > recognition.=20 > >=20 > > <>=20 > >=20 > >=20 > >=20 > > Best Regards,=20 > > Markus Rentschler=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 11:51:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22208; Tue, 4 Nov 2003 11:51:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4OU-0000YI-7v; Tue, 04 Nov 2003 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Nw-0000WA-Oh for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 11:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22164 for ; Tue, 4 Nov 2003 11:50:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4Nv-0000ZN-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 11:50:27 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AH4Nv-0000ZK-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 11:50:27 -0500 Received: from prattle.redback.com ([155.53.12.9]) by manatick with esmtp (Exim 4.24) id 1AH4Nv-0007JL-Gt for dhcwg@ietf.org; Tue, 04 Nov 2003 11:50:27 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 54EF854D202; Tue, 4 Nov 2003 08:49:22 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12075-10; Tue, 4 Nov 2003 08:49:22 -0800 (PST) Received: from localhost.0.0.127.in-addr.arpa (hover.redback.com [155.53.42.186]) by prattle.redback.com (Postfix) with ESMTP id 42DFD54D207; Tue, 4 Nov 2003 08:49:21 -0800 (PST) Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt From: Greg Kilfoyle To: Ralph Droms Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> References: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Content-Type: text/plain Message-Id: <1067964388.23897.378.camel@gar.kilfoyle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-2) Date: 04 Nov 2003 08:46:29 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I decided to take a more active role in this WG rather than be a casual observer. I don't have others' advantage (?) of going through the evolution of this draft - it's a lot to consume all at once. I'm also not sure what qualifies a person for voting on a draft. Is it just a member of this list that has read the draft or is there more to it? I'm in favor for advancing this draft except for 1 item which I need cleared up - the payload offset is listed as 8 bytes but it appears to me it should be 12 bytes. The ISC code has it as 12 bytes. Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 12:10:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23082; Tue, 4 Nov 2003 12:10:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4gt-0002wL-26; Tue, 04 Nov 2003 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4g4-0002v7-7l for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 12:09:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23054 for ; Tue, 4 Nov 2003 12:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4g2-0000sU-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:09:10 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH4g2-0000s2-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:09:10 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2003 09:12:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA4H8bmU017725; Tue, 4 Nov 2003 09:08:38 -0800 (PST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS10617; Tue, 4 Nov 2003 12:08:36 -0500 (EST) Message-Id: <4.3.2.7.2.20031104120359.025886c0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Nov 2003 12:08:35 -0500 To: Greg Kilfoyle , Ralph Droms From: Kim Kinnear Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Cc: dhcwg@ietf.org In-Reply-To: <1067964388.23897.378.camel@gar.kilfoyle.com> References: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:46 AM 11/4/2003, Greg Kilfoyle wrote: >I decided to take a more active role in this WG rather than be a casual >observer. I don't have others' advantage (?) of going through the >evolution of this draft - it's a lot to consume all at once. On the other hand, (as you have already shown below) you may well see things that other folks will overlook because they've read it too many times already. >I'm also not sure what qualifies a person for voting on a draft. Is it >just a member of this list that has read the draft or is there more to >it? Those are precisely the qualifications necessary -- you have to be on this list, and (while there won't be a pop quiz to verify this) it is considered appropriate to have read a draft on which you wish to comment. >I'm in favor for advancing this draft except for 1 item which I need >cleared up - the payload offset is listed as 8 bytes but it appears to >me it should be 12 bytes. The ISC code has it as 12 bytes. Nice catch -- you are correct, it should be 12 bytes. We'll make that correction when we next update the draft. Cheers -- Kim >Cheers, Greg. >-- >Greg Kilfoyle > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 12:16:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23334; Tue, 4 Nov 2003 12:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4mg-0003BY-Fh; Tue, 04 Nov 2003 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4lw-0003Ab-75 for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 12:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23281 for ; Tue, 4 Nov 2003 12:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4lu-0000yX-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:15:14 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AH4lu-0000wT-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:15:14 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AH4lN-0002B6-00; Tue, 04 Nov 2003 09:14:41 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5WZ1H>; Tue, 4 Nov 2003 09:14:19 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: Interface Information Option Date: Tue, 4 Nov 2003 09:14:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A2F7.140B90F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A2F7.140B90F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Urspr=FCngliche Nachricht----- > Von: Kostur, Andre [SMTP:Andre@incognito.com] > Gesendet am: Dienstag, 4. November 2003 00:15 > An: 'Rentschler, Markus'; dhcwg@ietf.org > Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions / > Interface Informati on Option >=20 >=20 > Regarding: DHCP Interface Information Option=20 >=20 > - According to RFC 2131, a DHCP Server MUST NOT supply=20 > a Parameter > Request List option to a client (in OFFER, ACK, or NAK), thus a = server > cannot request this option. >=20 > [MR>] Ok. Then a client that has multiple interfaces=20 > SHOULD always > send the Interface Information Option to the server, without=20 > any request. > That wouldn't violate the restriction you've mentioned. Assuming that a client SHOULD always send the IIO to the server, what = does it fill it with in the original Discover? At this point it has never recieved a Server->Client packet. What benefit does this particular option give over simply using the = existing Client Identifier (Opt 61) to encode such information? (Which still = doesn't address what happens on the original Discover) You note in section 1: The relay agent information option [RFC 3046], which is added by a relay agent to a client's request to the server, contains in its Circuit ID sub option the number of the physical interface on which the relay received this client's request.. Keep in mind that devices using opt 82 aren't required to have a = circuit ID. The wording of the above should reflect that a device MAY add a circuit = ID. As well, the service cannot assume what the contents of a Circuit ID represents. ------_=_NextPart_001_01C3A2F7.140B90F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: Interface Information Option

        -----Urspr=FCngliche Nachricht-----
>       = Von:    Kostur, Andre [SMTP:Andre@incognito.com]
>       Gesendet = am:    Dienstag, 4. November 2003 00:15
>       = An:     'Rentschler, Markus'; dhcwg@ietf.org
>       = Betreff:        RE: [dhcwg] ID's: = DHCP Discovery Extensions /
> Interface Informati on Option
>
>
>       Regarding: DHCP = Interface Information Option
>
>       - According to = RFC 2131, a DHCP Server MUST NOT supply
> a Parameter
> Request List option to a client (in OFFER, ACK, = or NAK), thus a server
> cannot request this option.
>
>       [MR>]  = Ok. Then a client that has multiple interfaces
> SHOULD always
> send the Interface Information Option to the = server, without
> any request.
> That wouldn't violate the restriction you've = mentioned.

Assuming that a client SHOULD always send the IIO to = the server, what does it fill it with in the original Discover?  = At this point it has never recieved a Server->Client = packet.

What benefit does this particular option give over = simply using the existing Client Identifier (Opt 61) to encode such = information? (Which still doesn't address what happens on the original = Discover)

You note in section 1:

   The relay agent information option [RFC = 3046], which is added by
   a relay agent to a client's request to = the server, contains in its
   Circuit ID sub option the number of the = physical interface on which
   the relay received this client's = request..

Keep in mind that devices using opt 82 aren't = required to have a circuit ID.  The wording of the above should = reflect that a device MAY add a circuit ID.  As well, the service = cannot assume what the contents of a Circuit ID represents.

------_=_NextPart_001_01C3A2F7.140B90F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 12:59:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25292; Tue, 4 Nov 2003 12:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5SH-0006v6-0D; Tue, 04 Nov 2003 12:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5RV-0006sf-75 for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 12:58:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25244 for ; Tue, 4 Nov 2003 12:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5RT-0001nG-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:58:11 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AH5RS-0001mm-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 12:58:10 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AH5Qv-0002bq-00; Tue, 04 Nov 2003 09:57:37 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5WZH3>; Tue, 4 Nov 2003 09:57:15 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Tue, 4 Nov 2003 09:57:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A2FD.110C7300" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A2FD.110C7300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > -----Urspr=FCngliche Nachricht----- > > Von: Kostur, Andre [SMTP:Andre@incognito.com] > > Gesendet am: Dienstag, 4. November 2003 00:15 > > An: 'Rentschler, Markus'; dhcwg@ietf.org > > Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface > > Informati on Option > >=20 > ....=20 >=20 > > Regarding: DHCP Discovery Extensions=20 > >=20 > > - I think there's some overlap here. What's different between a > > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203)=20 > (Functionally speaking). > > Both of them cause a device to acquire new configuration=20 > information. > [MR>] =20 > To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must already > have a lease assigned! True, the device must already have a DHCP state machine running. But = if there's no state machine running, then the device is choosing to not = use DHCP! > With the Discovery Extensions I try to overcome this.=20 > It's in fact a different philosophy to "traditional"=20 > DHCP, even a > different protocol, that just uses the DHCP packet format and the = DHCP > infrastructure!! This point must be clearly understood. So you're trying to say that this draft only pertains to unconfigured devices? And that DHCP servers should be extended to hold information = about devices that aren't performing DHCP (If it is performing DHCP, then the server will learn about the device when it Discovers....)? (Are we = then duplicating effort with other protocols/applications which deal with = the network discovery stuff such as SNMP workstations?) =20 > Right now there are some proprietary Discovery Protocols under > development by some industry consortiums that go into that direction. > But I don't want yet another proprietary packet format=20 > and protocol > infrastructure if I can easily adopt DHCP, which does familiar things > anyway. Thats the background of my draft. OK, but DHCP isn't a device discovery protocol (and IMHO, shouldn't be. = And devices which are configured to be using DHCP will, at some point, = broadcast Discover, at which point the device will be "discovered"). And there = is at least one other "Discovery Protocol" mechanism that would work almost = as well (using existing protocols)... performing ICMP Echos to determine = if there is a device, followed by performing an SNMP Walk on the target = device. (Note that later on you mention a target environment of a factory = floor, so we wouldn't need to worry about firewalls getting in the way....) > > - The DHCP Client behaviour talks about an "initially=20 > granting server", > > what if the device has not yet been granted a lease from any = server? > [MR>] See my point above. In that case it is configuration, not > reconfiguration!=20 > Reconfiguration should be restricted to the initially granting > server, but not configuration. But then the draft is confusing. The draft talks about an initially granting server (thus the device already has a lease), and you're = talking about configuration (thus the device has no initially granting = server).... > > - I don't think this draft really takes into consideration=20 > the scope of > > where DHCP is used. According to the draft, a DHCPNETSCAN may be > > broadcast, and should be relayed onto all other subnets. Thus if a > > central DHCP server emits 1 of these messages, that will=20 > result in it > > being broadcast to _everything_ on an entire intranet. And=20 > what about > > relays behind relays? What about relays that aren't on the=20 > same subnet as > > the originating server? And then there's the problem of = potentially > > hundreds of thousands of devices _all_ trying to DHCPREPORT=20 > back to the > > server within a 2 second timeframe! > [MR>] For this reason I propose to make this mechanism > (Broadcasting over relays) configurable. Then it's entirely in the > responsibility of the network administrator, if he wants to take the > potential risk having his network flooded with broadcasts.I see the > application of the discovery mechanism mainly in networks that run on > factory floors, which are not publicly accessible and consist=20 > of lets say a > maximum of ten thousand devices. Sure it's configurable. But your draft sets it up in the default case = that "A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay agent's other subnets." (Actually, I just noticed that by default the = draft wants all REPORTs to be broadcast too... so that one DHCPNETSCAN which = is sent across your network results in potentially everybody on your = network broadcasting back to you.... now there's an efficient DDoS attack on = your entire DHCP infrastructure!) > I also proposed in my draft to restrict broadcasting to certain > relay interfaces, using the giaddr-field and/or the relay=20 > agent information > option. I think this would be very useful for security reasons and > scalability (the server will be able to scan subnet for=20 > subnet or interface > for interface) >=20 >=20 > > - DHCPREPORT says that option 61 is to be supplied. There is no > > requirement that a client _has_ a clientID. It also says=20 > that option 3 is > > to be supplied too. A device may not have a router defined. > [MR>] "The client MUST omit any parameters it cannot=20 > provide." (see > chapter 5). This should of course also be mentioned in chapter 3.3. You may wish to reword that to something along the lines of "these = options are required to be sent by the client, all other options MAY (MUST?) be included if the client has pertinent information". > > - DHCPCONFIGURE is very disruptive to the network. If all the > > administrator changed was the client's DNS settings (for=20 > example), this > > draft requires the client to RELEASE it's existing lease,=20 > and then assume > > the new settings.=20 > [MR>] The Discovery Extensions rely heavily on the server. The > people that implement and/or operate the server need to know=20 > what they are > doing. Of course can misuse of he server disrupt the network.=20 > I can' t see > any other strategy to prevent that than firing the admin if=20 > he misuses the > server under his control ;-)). >=20 > > It's a little foggy as to what the DHCP server is going to=20 > do when it > > receives this RELEASE message. =20 > [MR>] Standard RFC2131 behaviour: The server has to check its > internal lease database and relase that lease.=20 > Sending a RELEASE is mainly for backward compatibility=20 > with RFC 2131 > if there is a server on the network that doesn't support the = discovery > extensions. >=20 > > The draft also doesn't specify what order the RELEASE and=20 > REPORT are to be > > sent in. > [MR>] First RELEASE then REPORT. OK, what happens in the case: 1) Device A sends the RELEASE 2) Device B Discovers & Requests (since the IP is now available, it was = just released!) the now released IP 3) Device A REPORTs on that IP ? > > - In section 3 you state: "To existing correct=20 > implementations of BOOTP > > relay agents these new message types SHOULD be=20 > transparent." This is > > incorrect. For DHCPNETSCAN (A server-to-client message),=20 > the bootp relay > > agent is supposed to broadcast that message on all connected = subnets > > (except the one it was received on). This is not the=20 > "normal" behaviour > > of a relay agent. > [MR>] This describes the desired extended behaviour=20 > defined in my > draft. An existing relay agent that does not support the=20 > discovery extension > should never broadcast the DHCPNETSCAN packet.=20 >=20 > > In the abstact these are the stated goals:=20 > > - Discovery of clients in the network=20 > > - DHCP server redundancy=20 > > - Server-initiated configuration of clients=20 > >=20 > > DHCP server redundancy is already covered in the Failover draft. > [MR>] This is true. But server redundancy is not the=20 > main purpose > of the discovery extension. It's a nice "side-effect" and=20 > IMHO much less Not to sound nasty, but if this isn't a purpose of the discovery = extension, why is it stated as a goal of the draft? > complicated than the failover protocol. But server redundancy=20 > only works > with clients that are able to broadcast DHCPREPORT messages.=20 > It will not > work with old BOOTP and DHCP clients, since they are unable=20 > to tell other > servers about their configuration. >=20 > > Server-initiated configuration is covered in RFC 3203. =20 > I'm not sure > > that this draft can even do the Discovery of clients in the=20 > network, as > > any device which doesn't perform DHCP would be completely=20 > invisible to > > this scheme (as would any device which doesn't implement=20 > this draft). > [MR>] For not beeing invisible, a device needs at least to be > capable of BOOTP or DHCP, since they tell the server "Hey,=20 > I'm here!". For > silent discovery, the clients of course need to be capable of=20 > the Discovery > Extensions. Another general comment about the draft. Offhand I think the = DHCPCONFIGURE message is superfluous when there exists RFC 3203. I don't see = anything that that DHCPCONFIGURE does that DHCPRECONFIGURE can't do. In the = case of an "unconfigured" client, there's nothing that needs to be done except = wait for the device to naturally Discover. For an already configured device = we can send a FORCERENEW, and the device will immediately transition to = the Renewing state, causing it to perform a REQUEST/ACK sequence, at which = point the device can reconfigure itself based upon the data in the new ACK = packet. ------_=_NextPart_001_01C3A2FD.110C7300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: DHCP Discovery Extensions

> > -----Urspr=FCngliche Nachricht-----
> > = Von:        Kostur, Andre = [SMTP:Andre@incognito.com]
> > Gesendet = am:        Dienstag, 4. November = 2003 00:15
> > An: 'Rentschler, Markus'; = dhcwg@ietf.org
> > Betreff:    RE: [dhcwg] = ID's: DHCP Discovery Extensions / Interface
> > Informati on Option
> >
>       ....
>
> > Regarding: DHCP Discovery Extensions =
> >
> > - I think there's some overlap here.  = What's different between a
> > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC = 3203)
> (Functionally speaking).
> > Both of them cause a device to acquire new = configuration
> information.
>       [MR>]  =
>       To use = DHCPFORCERENEW (DHCPRECONFIGURE), the client must already
> have a lease assigned!

True, the device must already have a DHCP state = machine running.  But if there's no state machine running, then = the device is choosing to not use DHCP!

>       With the = Discovery Extensions I try to overcome this.
>       It's in fact a = different philosophy to "traditional"
> DHCP, even a
> different protocol, that just uses the DHCP = packet format and the DHCP
> infrastructure!! This point must be clearly = understood.

So you're trying to say that this draft only pertains = to unconfigured devices?  And that DHCP servers should be extended = to hold information about devices that aren't performing DHCP (If it is = performing DHCP, then the server will learn about the device when it = Discovers....)?  (Are we then duplicating effort with other = protocols/applications which deal with the network discovery stuff such = as SNMP workstations?)

 
>       Right now there = are some proprietary Discovery Protocols under
> development by some industry consortiums that = go into that direction.
>       But I don't want = yet another proprietary packet format
> and protocol
> infrastructure if I can easily adopt DHCP, = which does familiar things
> anyway. Thats the background of my = draft.

OK, but DHCP isn't a device discovery protocol (and = IMHO, shouldn't be.  And devices which are configured to be using = DHCP will, at some point, broadcast Discover, at which point the device = will be "discovered").  And there is at least one other = "Discovery Protocol" mechanism that would work almost as well = (using existing protocols)... performing ICMP Echos to determine if = there is a device, followed by performing an SNMP Walk on the target = device.  (Note that later on you mention a target environment of a = factory floor, so we wouldn't need to worry about firewalls getting in = the way....)

> > - The DHCP Client behaviour talks about an = "initially
> granting server",
> > what if the device has not yet been = granted a lease from any server?
>       [MR>]  = See my point above. In that case it is configuration, not
> reconfiguration!
>       Reconfiguration = should be restricted to the initially granting
> server, but not configuration.

But then the draft is confusing.  The draft = talks about an initially granting server (thus the device already has a = lease), and you're talking about configuration (thus the device has no = initially granting server)....

> > - I don't think this draft really takes = into consideration
> the scope of
> > where DHCP is used.  According to the = draft, a DHCPNETSCAN may be
> > broadcast, and should be relayed onto all = other subnets.  Thus if a
> > central DHCP server emits 1 of these = messages, that will
> result in it
> > being broadcast to _everything_ on an = entire intranet.  And
> what about
> > relays behind relays?  What about = relays that aren't on the
> same subnet as
> > the originating server?  And then = there's the problem of potentially
> > hundreds of thousands of devices _all_ = trying to DHCPREPORT
> back to the
> > server within a 2 second timeframe!
>       [MR>]  = For this reason I propose to make this mechanism
> (Broadcasting over relays) configurable. Then = it's entirely in the
> responsibility of the network administrator, if = he wants to take the
> potential risk having his network flooded with = broadcasts.I see the
> application of the discovery mechanism mainly = in networks that run on
> factory floors, which are not publicly = accessible and consist
> of lets say a
> maximum of ten thousand devices.

Sure it's configurable.  But your draft sets it = up in the default case that "A broadcasted DHCPNETSCAN message = SHOULD be broadcasted into a relay agent's other subnets."  = (Actually, I just noticed that by default the draft wants all REPORTs = to be broadcast too... so that one DHCPNETSCAN which is sent across = your network results in potentially everybody on your network = broadcasting back to you.... now there's an efficient DDoS attack on = your entire DHCP infrastructure!)

>       I also proposed = in my draft to restrict broadcasting to certain
> relay interfaces, using the giaddr-field and/or = the relay
> agent information
> option. I think this would be very useful for = security reasons and
> scalability (the server will be able to scan = subnet for
> subnet or interface
> for interface)
>
>
> > - DHCPREPORT says that option 61 is to be = supplied.  There is no
> > requirement that a client _has_ a = clientID.  It also says
> that option 3 is
> > to be supplied too.  A device may not = have a router defined.
>       [MR>]  = "The client MUST omit any parameters it cannot
> provide." (see
> chapter 5). This should of course also be = mentioned in chapter 3.3.

You may wish to reword that to something along the = lines of "these options are required to be sent by the client, all = other options MAY (MUST?) be included if the client has pertinent = information".

> > - DHCPCONFIGURE is very disruptive to the = network.  If all the
> > administrator changed was the client's DNS = settings (for
> example), this
> > draft requires the client to RELEASE it's = existing lease,
> and then assume
> > the new settings.
>       [MR>]  = The Discovery Extensions rely heavily on the server. The
> people that implement and/or operate the server = need to know
> what they are
> doing. Of course can misuse of he server = disrupt the network.
> I can' t see
> any other strategy to prevent that than firing = the admin if
> he misuses the
> server under his control ;-)).
>
> >  It's a little foggy as to what the = DHCP server is going to
> do when it
> > receives this RELEASE message.  =
>       [MR>]  = Standard RFC2131 behaviour: The server has to check its
> internal lease database and relase that lease. =
>       Sending a = RELEASE is mainly for backward compatibility
> with RFC 2131
> if there is a server on the network that = doesn't support the discovery
> extensions.
>
> > The draft also doesn't specify what order = the RELEASE and
> REPORT are to be
> > sent in.
>       [MR>]  = First RELEASE then REPORT.

OK, what happens in the case:

1) Device A sends the RELEASE
2) Device B Discovers & Requests (since the IP = is now available, it was just released!) the now released IP
3) Device A REPORTs on that IP

?

> > - In section 3 you state: "To existing = correct
> implementations of BOOTP
> > relay agents these new message types = SHOULD be
> transparent."  This is
> > incorrect.  For DHCPNETSCAN (A = server-to-client message),
> the bootp relay
> > agent is supposed to broadcast that = message on all connected subnets
> > (except the one it was received on).  = This is not the
> "normal" behaviour
> > of a relay agent.
>       [MR>]  = This describes the desired extended behaviour
> defined in my
> draft. An existing relay agent that does not = support the
> discovery extension
> should never broadcast the DHCPNETSCAN packet. =
>
> > In the abstact these are the stated goals: =
> >    - Discovery of clients = in the network
> >    - DHCP server redundancy =
> >    - Server-initiated = configuration of clients
> >
> > DHCP server redundancy is already covered = in the Failover draft.
>       [MR>]  = This is true. But server redundancy is not the
> main purpose
> of the discovery extension. It's a nice = "side-effect" and
> IMHO much less

Not to sound nasty, but if this isn't a purpose of = the discovery extension, why is it stated as a goal of the = draft?

> complicated than the failover protocol. But = server redundancy
> only works
> with clients that are able to broadcast = DHCPREPORT messages.
> It will not
> work with old BOOTP and DHCP clients, since = they are unable
> to tell other
> servers about their configuration.
>
> >   Server-initiated configuration = is covered in RFC 3203. 
> I'm not sure
> > that this draft can even do the Discovery = of clients in the
> network, as
> > any device which doesn't perform DHCP = would be completely
> invisible to
> > this scheme (as would any device which = doesn't implement
> this draft).
>       [MR>]  = For not beeing invisible, a device needs at least to be
> capable of BOOTP or DHCP, since they tell the = server "Hey,
> I'm here!".  For
> silent discovery, the clients of course need to = be capable of
> the Discovery
> Extensions.


Another general comment about the draft.  = Offhand I think the DHCPCONFIGURE message is superfluous when there = exists RFC 3203.  I don't see anything that that DHCPCONFIGURE = does that DHCPRECONFIGURE can't do.  In the case of an = "unconfigured" client, there's nothing that needs to be done = except wait for the device to naturally Discover.  For an already = configured device we can send a FORCERENEW, and the device will = immediately transition to the Renewing state, causing it to perform a = REQUEST/ACK sequence, at which point the device can reconfigure itself = based upon the data in the new ACK packet.

------_=_NextPart_001_01C3A2FD.110C7300-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 13:46:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27187; Tue, 4 Nov 2003 13:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6Bl-0002N2-CO; Tue, 04 Nov 2003 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6Ar-0002Lx-Fl for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 13:45:05 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27155 for ; Tue, 4 Nov 2003 13:44:53 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AH69T-0001Zp-ND; Tue, 04 Nov 2003 13:43:39 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Tue, 04 Nov 2003 13:43:39 -0500 Subject: [dhcwg] REVISED Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'A Guide to Implementing Stateless DHCPv6 Service' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 13:51:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27527; Tue, 4 Nov 2003 13:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6Gc-0002YQ-Bn; Tue, 04 Nov 2003 13:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6G1-0002Xj-1J for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 13:50:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27472 for ; Tue, 4 Nov 2003 13:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6Fy-0002dM-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 13:50:22 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AH6Fy-0002dJ-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 13:50:22 -0500 Received: from prattle.redback.com ([155.53.12.9]) by manatick with esmtp (Exim 4.24) id 1AH6Ft-0002Aq-Cw for dhcwg@ietf.org; Tue, 04 Nov 2003 13:50:17 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 26FCD8A7132 for ; Tue, 4 Nov 2003 10:49:15 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16125-06 for ; Tue, 4 Nov 2003 10:49:14 -0800 (PST) Received: from dhcp-41-99.redback.com (dhcp-41-99.redback.com [155.53.41.99]) by prattle.redback.com (Postfix) with ESMTP id D5E4A8A713B for ; Tue, 4 Nov 2003 10:49:14 -0800 (PST) Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt From: Greg Kilfoyle To: dhcwg@ietf.org In-Reply-To: <200310271419.JAA14690@ietf.org> References: <200310271419.JAA14690@ietf.org> Content-Type: text/plain Message-Id: <1067971754.2741.11.camel@dhcp-41-99.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-1) Date: Tue, 04 Nov 2003 10:49:14 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support advancing this draft. Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 15:31:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03983; Tue, 4 Nov 2003 15:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7pO-0002Kv-C5; Tue, 04 Nov 2003 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7oz-0002K8-U1 for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 15:30:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03935 for ; Tue, 4 Nov 2003 15:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7oy-0004gz-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 15:30:36 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AH7ox-0004gw-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 15:30:35 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id B25671C01224 for ; Tue, 4 Nov 2003 12:30:31 -0800 (PST) Received: (from ksenthil@localhost) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) id BAA06679; Wed, 5 Nov 2003 01:59:18 +0530 (IST) From: SENTHIL KUMAR BALASUBRAMANIAN Message-Id: <200311042029.BAA06679@iconsrv5.india.hp.com> To: dhcwg@ietf.org Date: Wed, 5 Nov 2003 01:59:17 +0530 (IST) Cc: pbpatel@india.hp.com X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1067977757-6132-0_ Content-Transfer-Encoding: 7bit Subject: [dhcwg] ID on Proxy Server Configuration using DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --ELM1067977757-6132-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Herewith, I have attached a new draft on proxy server configuration option for DHCP. Following is the abstract of this draft Abstract This document defines a new Dynamic Host Configuration Protocol (DHCP) option, which can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc. Proxy Server provides controlled and efficient access to the Internet by access control mechanism for different types of user requests and caching frequently accessed information (Web pages and possibly files that might have been downloaded using FTP and other protocols). Please go through the same and give me your comments. I will submit this draft to the IETF once the queue is opened. --ELM1067977757-6132-0_ Content-Type: application/octet-stream Content-Disposition: attachment; filename=draft-ietf-dhc-proxyserver-opt-00.txt Content-Description: draft-ietf-dhc-proxyserver-opt-00.txt Content-Transfer-Encoding: quoted-printable =0ADHC Working Group Senthil K Balasubramani= an=0AInternet-Draft Hewlett-Packard Com= pany=0AExpires: March 31, 2004 Oc= t 2003=0A=0A=0A DHCP Option for Proxy Server Configuration=0A= draft-ietf-dhc-proxyserver-opt-00.txt=0A=0AStatus of this= Memo=0A=0A This document is an Internet-Draft and is in full conformance= with=0A all provisions of Section 10 of RFC2026.=0A=0A Internet-Drafts= are working documents of the Internet Engineering=0A Task Force (IETF), = its areas, and its working groups. Note that other=0A groups may also dis= tribute working documents as Internet-Drafts.=0A=0A Internet-Drafts are d= raft documents valid for a maximum of six months=0A and may be updated, r= eplaced, or obsoleted by other documents at any=0A time. It is inappropri= ate to use Internet-Drafts as reference=0A material or to cite them other= than as "work in progress."=0A=0A The list of current Internet-Drafts ca= n be accessed at http://=0A www.ietf.org/ietf/1id-abstracts.txt.=0A=0A = The list of Internet-Draft Shadow Directories can be accessed at=0A http:= //www.ietf.org/shadow.html.=0A=0A This Internet-Draft will expire on Marc= h 31, 2004.=0A=0ACopyright Notice=0A=0A Copyright (C) The Internet Societ= y (2003). All Rights Reserved.=0A=0AAbstract=0A=0A This document defines = a new Dynamic Host Configuration Protocol=0A (DHCP) option, which can be = used to configure the TCP/IP host's=0A Proxy Server configuration for sta= ndard protocols like HTTP, FTP,=0A NNTP, SOCKS, Gopher, SLL and etc. Prox= y Server provides controlled =0A and efficient access to the Internet by = access control mechanism =0A for different types of user requests and cac= hing frequently accessed=0A information (Web pages and possibly files tha= t might have been=0A downloaded using FTP and other protocols).=0A=0ATabl= e of Contents=0A=0A 1. Terminologies Used . . . . . . . . . . . . . . . .= . . . . . . 3=0A=0A 2. Introduction . . . . . . . . . . . . . . . . . .= . . . . . . . 4=0A=0A 3. Requirements terminology . . . . . . . . . . .= . . . . . . . . 4=0A=0A 4. Proxy Server Configuration Option . . . . .= . . . . . . . . . 5=0A=0A=0ASenthil Expires May 6, 20= 04 [Page 1]=0A=0C=0AInternet-Draft DHCP Option for Proxy = Server Configuration Nov 2003=0A=0A=0A 5. Option Usage . . . . . . . = . . . . . . . . . . . . . . . . . 5=0A=0A 6. Security Considerations . = . . . . . . . . . . . . . . . . . . 6=0A=0A 7. IANA Considerations . . = . . . . . . . . . . . . . . . . . . . 6=0A=0A 8. Acknowledgements . .= . . . . . . . . . . . . . . . . . . . . . 6=0A=0A 9. Normative Reference= s . . . . . . . . . . . . . . . . . . . . . 6=0A=0A 10. Informative Refe= rences . . . . . . . . . . . . . . . . . . . 6=0A=0A Author's Addre= ss . . . . . . . . . . . . . . . . . . . . . . 7=0A=0A Intellectual= Property . . . . . . . . . . . . . . . . . . . 7=0A=0A Copyright = Statements . . . . . . . . . . . . . . . . . . . . 8=0A=0A1. Terminologie= s Used=0A=0A DHCP Client: A DHCP [1] client is an Internet host that= uses=0A DHCP to obtain configuration information such as ne= twork=0A=09 address.=0A=0A DHCP Server: A DHCP server is an I= nternet host that returns=0A configuration parameters to DHC= P clients.=0A=0A Proxy Server: In a enterprise network that connects= to Internet,=0A a proxy server is a server that acts as an = intermediary=0A between a workstation user and the Internet = so that the=0A enterprise can ensure security, administrativ= e control,=0A and caching service. A Proxy server MAY be ass= ociated with=0A or part of a gateway server that separates t= he enterprise=0A network from the outside network (Usually I= nternet)=0A and a firewall server that protects the enterpri= se network=0A from outside intrusion.=0A=0A HTTP: A= protocol (RFC 2068, Hypertext Transfer Protocol,=0A utilizi= ng TCP) to transfer hypertext request and =0A information be= tween servers and browsers.=0A=0A FTP: A protocol (RFC 959, File = Transfer Protocol Utilizing TCP)=0A that allows users to cop= y file(s) between their local =0A system and any other syste= m, which is reachable on the =0A network.=0A=0A SSL := A protocol (Secure Sockets Layer), which provides =0A enc= rypted communications on the Internet.=0A=09=0A NNTP : A Protocol (= RFC 977, Network News Transfer Protocol) for=0A the distribu= tion, inquiry, retrieval and posting of news=0A articles ove= r the Internet, using a reliable stream based=0A transmissio= n.=0A=0A=0A=0ASenthil Expires May 6, 2004 = [Page 2]=0A=0C=0AInternet-Draft DHCP Option for Proxy Server Configura= tion Nov 2003=0A=0A Gopher: A Protocol (RFC 1436) designed for dis= tributed document=0A search and retrieval.=0A=0A SOCK= S: SOCKSv5 is an approved standard (RFC 1928) generic,=0A p= roxy protocol for TCP/IP based networking applications.=0A=20= The SOCKS protocol provides flexible framework for =0A = developing secure communications by easily integrating =0A = other security technologies.=0A=0A WAIS : A protocol (Wide= Area Information Server) designed for =0A wide-area network= ed-baed information system for searching,=0A browsing and pu= blishing.=0A=0A2. Introduction=0A=0A The Dynamic Host Configuration Proto= col [1] provides a framework for =0A passing configuration information to= hosts on a TCP/IP network.=0A However, the configuration capability prov= ided by DHCP does not=0A include Proxy(HTTP, FTP, NNTP, Gopher etc.)serve= r configuration to=0A be used so as to have controlled and/or efficient a= ccess to the=0A Internet from within a firewall/enterprise network.=0A=0A= Following Figure, depicts the typical setup of a secure subnet=0A insi= de a firewall with Proxy server.=0A=0A +---------------------------+=09= =09+-----------+=0A | |=09=09|Remote HTTP|=09= =0A | |=09HTTP=09|Server=09 |=0A | +-----= -------+ +-------------+<--->+-----------+=0A | | Clients | = |Proxy Server |=0A | | Inside the |<------>| + | FTP +---= --------+=0A | | Firewall | |Firewall |<--->|Remote FTP |= =0A | +------------+ +-------------+=09|Server=09 |=0A | = | ^=09=09+-----------+=0A | = | |=0A | | |=09=09+-----------+=0A +--= -------------------------+ | NNTP=09|Remote NNTP|=0A=09=09=09=09 +------= ------>|Server=09 |=0A=09=09=09=09=09 +-----------+=0A=0A The p= rimary use of proxies is to allow access to the WWW =0A (World Wide Web) = from within a firewall. A proxy is a special =0A software typically runs = on firewall machine, waits for a request =0A from inside the firewall, fo= rwards the request to the remote server=0A outside the firewall, reads th= e response and then sends it back to=0A the client. Usually, all the clie= nts use the same proxy within a =0A given network, which helps in efficie= nt caching of documents that =0A are requested by a number of clients. Th= is behavior makes proxies =0A attractive to clients not inside a firewall= .=0A=0A Proxy server increases the network security and user productivity= =0A by content filtering and controlling both internal and external =0A = access to information. Also, it provides several other =0A functionalit= ies that are not discussed here.=0A=0A=0A=0ASenthil Exp= ires May 6, 2004 [Page 3]=0A=0C=0AInternet-Draft DHCP Opt= ion for Proxy Server Confi= guration Nov 2003=0A=0A3. Requirements terminology=0A=0A The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A "SHOULD", "SHOUL= D NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A document are to b= e interpreted as described in RFC 2119 [3].=0A=0A4. Proxy Server Configurat= ion Option=0A=0A This document defines a new DHCP Option called the Proxy= Server =0A Configuration Option. The format of the Proxy Server configur= ation=0A option is:=0A=0A =09 Code Len Proxy Server Configurati= on Sub Option=0A =09 +-------+------+------+------+------+------+-....-+-= -----+=0A =09 | TBD | N | a1 | a2 | a3 | a4 | | aN |= =0A =09 +-------+------+------+------+------+------+-....-+------+=0A=0A = Code is TBD as per RFC-2939 [4]. The length N gives the total number=0A = of octets in the Proxy Server Configuration Sub Option. The minimum=0A l= ength is 8 octets. The Proxy Server Configuration sub option consists =0A = of a sequence of SubOpt/Length/Value tuples for each sub option encoded=0A= in the following manner:=0A=0A The format Proxy Server Configuration s= ub Option is:=0A=0A =09 SubOpt Len =09 IP Address=09 Port (2 = octet)=0A =09 +-------+------+------+------+------+------+------+------+= =0A =09 | t=09 | N | a1 | a2 | a3 | a4 | port |=0A = =09 +-------+------+------+------+------+------+------+------+=0A=0A More= than one Sub Option MAY be specified for the same protocol.=0A In that c= ase, the precedence MUST be given in the order in which=0A these options = were received by the client. The first one received=0A shall be given hig= her priority and so on. The SubOpt field t =0A specifies the type of Prot= ocol and MUST be one of the protocol =0A number.=0A =0A +--------= -----------------------+=0A | protocol | Number |=0A = +-------------------------------+=0A | HTTP | TBD = |=0A +-------------------------------+=0A | FTP | = TBD |=0A +-------------------------------+=0A | NNTP= | TBD |=0A +-------------------------------+=0A = | Gopher | TBD |=0A +----------------------------= ---+=0A | SSL | TBD |=0A +-----------------= --------------+=0A | SOCKS | TBD |=0A +------= -------------------------+=0A | WAIS | TBD |=0A = +-------------------------------+=0A=0A=0A=0ASenthil = Expires May 6, 2004 [Page 4]=0A=0C=0AInternet-Draft DHC= P Option for Proxy Server Configuration Nov 2003=0A=0A DHCP server shou= ld send the p= ort field (port number) in Network Byte=0A Order.=0A=0A5. Option Usage=0A= =0A The Proxy Server Configuration field shall NOT be terminated with a= =0A 255 sub-option. The length N of the DHCP Proxy Server Configuration= =0A Option shall include all bytes of the sub-option code/length/value=0A= tuples. The length N of the sub-options shall be the number of octets=0A= in only that sub-option's value field. The port MUST be a valid=0A TCP= /UDP port. The minimum length of a sub-option is 6 octets. =0A The sub-op= tions need not appear in protocol type order.=0A=0A8. Security Consideratio= ns=0A=0A The DHCP Options defined here allow an unauthorized DHCP server= to=0A misdirect a client to access nonexistent/erring Proxy Server due = to =0A which the connection to the Internet might be denied.=0A =0A = DHCP provides an authentication mechanism, as described in RFC 3118=0A = [3], which may be used if authentication is required.=0A=0A=0A9. IANA Consi= derations=0A =0A IANA is requested to assign an option code to the Prox= y Server=0A Configuration Option and protocol numbers for the sub option.= =0A=0A IANA is also requested to maintain a new number space for the =0A = Proxy Server Configuration sub options.=0A=0A10. Acknowledgements=0A=0A = Thanks to Srinivas Reddy and Sridhar Ramamoorthy of Satyam InfoWay =0A f= or their extended help in technical Queries.=0A=0A11. Normative References= =0A=0A [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,= =0A March 1997.=0A=0A [2] Alexander, S. and R. Droms, "DHCP Optio= ns and BOOTP Vendor=0A Extensions", RFC 2132, March 1997.=0A=0A [3= ] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",=0A=09 RFC 3= 118, June 2001.=0A=0A=0A12. Informative References=0A=0A [4] Bradner, S= ., "Key words for use in RFCs to Indicate Requirement=0A Levels", B= CP 14, RFC 2119, March 1997.=0A=0A [5] Droms, R., "Procedures and IANA G= uidelines for Definition of=0A New DHCP Options and Message Types",= BCP 43, RFC 2939,=0A=0A=0ASenthil Expires May 6, 2004 = [Page 5]=0A=0C=0AInternet-Draft DHCP Option for Proxy Ser= ver Configuration Nov 2003=0A=0A September 2000.=0A=0A [6] Nar= ten, N. and H. Alvestrand, "Guidelines for Writing an IANA=0A=09 Considera= tions Section in RFCs", BCP 26, RFC 2434, October 1998.=0A=0AAuthor's Addre= ss=0A=0A Senthil K Balasubramanian=0A Hewlett Packard=0A 29 Cunnigham= Road,=0A Bangalore=0A India 560 052=0A =0A Phone: +91 80 205 310= 3=0A EMail: balasubramanian@hp.com=0A=0A=0AIntellectual Property Statemen= t=0A=0A The IETF takes no position regarding the validity or scope of any= =0A intellectual property or oth= er rights that might be claimed to=0A pertain to the implementation or us= e of the technology described in=0A this document or the extent to which = any license under such rights=0A might or might not be available; neither= does it represent that it=0A has made any effort to identify any such ri= ghts. Information on the=0A IETF's procedures with respect to rights in s= tandards-track and=0A standards-related documentation can be found in BCP= -11. Copies of=0A claims of rights made available for publication and any= assurances of=0A licenses to be made available, or the result of an atte= mpt made to=0A obtain a general license or permission for the use of such= =0A proprietary rights by implementors or users of this specification can= =0A be obtained from the IETF Secretariat.=0A=0A The IETF invites any i= nterested party to bring to its attention any=0A copyrights, patents or p= atent applications, or other proprietary=0A rights which may cover techno= logy that may be required to practice=0A this standard. Please address th= e information to the IETF Executive=0A Director.=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0ASenthil Expires May= 6, 2004 [Page 6]=0A=0C=0AInternet-Draft DHCP Option for = Proxy Server Configuration Nov 2003=0A=0AFull Copyright Statement=0A=0A = Copyright (C) The Internet Society (2003). All Rights Reserved.=0A=0A Th= is document and translations of it may be copied and furnished to=0A othe= rs, and derivative works that comment on or otherwise explain it=0A or as= sist in its implementation may be prepared, copied, published=0A and dist= ributed, in whole or in part, without restriction of any=0A kind, provide= d that the above copyright notice and this paragraph are=0A included on a= ll such copies and derivative works. However, this=0A document itself may= not be modified in any way, such as by removing=0A the copyright notice = or references to the Internet Society or other=0A Internet organizations,= except as needed for the purpose of=0A developing Internet standards in = which case the procedures for=0A copyrights defined in the Internet Stand= ards process must be=0A followed, or as required to translate it into lan= guages other than=0A English.=0A=0A The limited permissions granted abo= ve are perpetual and will not be=0A revoked by the Internet Society or it= s successors or assignees.=0A=0A This document and the information contai= ned herein is provided on an=0A "AS IS" basis and THE INTERNET SOCIETY AN= D THE INTERNET ENGINEERING=0A TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRES= S OR IMPLIED, INCLUDING=0A BUT NOT LIMITED TO ANY WARRANTY THAT TH= E USE OF THE INFORMATION=0A HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IM= PLIED WARRANTIES OF=0A MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOS= E.=0A=0A=0AAcknowledgment=0A=0A Funding for the RFC Editor function is cu= rrently provided by the=0A Internet Society.=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0ASenthil = Expires May 6, 2004 [Page 7]=0A=0C=0A= --ELM1067977757-6132-0_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 19:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12638; Tue, 4 Nov 2003 19:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBN3-0001N9-Cu; Tue, 04 Nov 2003 19:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBMC-0001JK-V4 for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 19:17:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12601 for ; Tue, 4 Nov 2003 19:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHBMB-0000Br-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 19:17:07 -0500 Received: from mail4.nmia.com ([64.42.128.68] helo=mail.nmia.com) by ietf-mx with smtp (Exim 4.12) id 1AHBMA-0000Bo-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 19:17:06 -0500 Received: (qmail 54341 invoked by uid 104); 5 Nov 2003 00:17:07 -0000 Received: from thecajun@nmia.com by mail.nmia.com by uid 101 with qmail-scanner-1.10 (uvscan: v4.0.70/v4301. spamassassin. Clear:0. Processed in 0.435513 secs); 05 Nov 2003 00:17:07 -0000 X-Qmail-Scanner-Mail-From: thecajun@nmia.com via mail.nmia.com X-Qmail-Scanner: 1.10 (Clear:0. Processed in 0.435513 secs) Received: from unknown (HELO ?127.0.0.1?) (64.42.136.99) by mail4.nmia.com with SMTP; 5 Nov 2003 00:17:06 -0000 Date: Tue, 04 Nov 2003 17:17:07 -0700 From: TheCajun To: dhcwg@ietf.org Message-Id: <20031104171024.D498.THECAJUN@nmia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mail4.nmia.com X-Spam-Status: No, hits=-4.9 required=200.0 tests=BAYES_00 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Getting DHCPNAK Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is the log. Most machines on the LAN do not have a problem. A few do this. This started to happen after switching from using Cisco 678 DHCP to Redhat Linux 7.1. I switched back to cisco so all may be opperational. But I wish to use Linux DHCP. The dhcpd.conf file is included below. Any advice is appreciated. I have already hunted the internet for tips and those I tried did nothing. Many Thanks, Durwin Nov 4 15:24:00 localhost dhcpd: DHCPDISCOVER from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:00 localhost dhcpd: Abandoning IP address 10.0.0.7: pinged before offer Nov 4 15:24:00 localhost dhcpd: DHCPREQUEST for 192.168.2.134 from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:00 localhost dhcpd: DHCPNAK on 192.168.2.134 to 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:04 localhost dhcpd: DHCPDISCOVER from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:04 localhost dhcpd: Abandoning IP address 10.0.0.30: pinged before offer Nov 4 15:24:04 localhost dhcpd: DHCPREQUEST for 192.168.2.134 from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:04 localhost dhcpd: DHCPNAK on 192.168.2.134 to 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:16 localhost dhcpd: DHCPDISCOVER from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:16 localhost dhcpd: DHCPREQUEST for 192.168.2.134 from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:16 localhost dhcpd: DHCPNAK on 192.168.2.134 to 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:17 localhost dhcpd: DHCPOFFER on 10.0.0.31 to 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:31 localhost dhcpd: DHCPDISCOVER from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:31 localhost dhcpd: DHCPOFFER on 10.0.0.31 to 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:32 localhost dhcpd: DHCPREQUEST for 192.168.2.134 from 52:54:00:e7:5c:2d via eth0 Nov 4 15:24:32 localhost dhcpd: DHCPNAK on 192.168.2.134 to 52:54:00:e7:5c:2d via eth0 authoritative; #ddns-update-style ad-hoc; #ddns-update-style interim; subnet 10.0.0.0 netmask 255.255.255.0 { # --- default gateway option routers 10.0.0.1; option subnet-mask 255.255.255.0; option domain-name "ehca.com"; option domain-name-servers 10.0.0.240,204.108.240.1,204.147.80.5; option time-offset -25200; # Mountain Standard Time # range dynamic-bootp 10.0.0.3 10.0.0.239; range 10.0.0.3 10.0.0.239; default-lease-time 172800; max-lease-time 172800; # we want the nameserver to appear at a fixed address # host labsrvr { # hardware ethernet 00:60:08:9B:A4:75; # fixed-address 10.0.0.240; # } } _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 4 23:06:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22148; Tue, 4 Nov 2003 23:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEvh-0000GX-Lu; Tue, 04 Nov 2003 23:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEvV-0000G8-Rz for dhcwg@optimus.ietf.org; Tue, 04 Nov 2003 23:05:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22125 for ; Tue, 4 Nov 2003 23:05:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHEvS-0003hS-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 23:05:46 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AHEvR-0003hP-00 for dhcwg@ietf.org; Tue, 04 Nov 2003 23:05:45 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hA545bAr088172; Tue, 4 Nov 2003 23:05:46 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Vijayabhaskar A K'" Cc: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Tue, 4 Nov 2003 23:05:44 -0500 Message-ID: <000001c3a352$1923acc0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <000b01c39fc1$db186760$38e62a0f@nt23056> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Vijay: I don't understand the suboption (1) encoding for the multiple servers = (ts field) and the bootfiles (fn fields). Perhaps something happened with = this document or it is incomplete? Please look it over. Perhaps it is my = problem, but if it isn't clear, I'm sure others will have similar issues. Why = don't you just use two suboptions, one for the list of TFTP servers to use and another for the bootfile names? Also, can the TFTP server names be IP addresses? Perhaps you should consider using the DNS wire format instead = of ASCII? I have a similar issue with the DHCPv6 draft. Seems to me if makes more sense to have two options - one to list the TFTP servers and another to = list the bootfiles? (I guess there could be an argument made that different bootfiles might be used with different servers???) It is also odd that = you would want to allow multiple TFTP server addresses in the DHCPv4 case, = but only allow one in the DHCPv6 case. Or have I missed something? One way around this problem might be to allow multiple OPTION_REMOTE_BOOT and = for each of these, one can have a list of server = (OPTION_REMOTE_BOOT_SERVERS) and one or more boot files (OPTION_REMOTE_BOOT_FILES). For each = instances of the OPTION_REMOTE_BOOT, the servers would all use the same boot files. However, if you want servers to use different boot files, you simply = specify multiple OPTION_REMOTE_BOOTs. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Vijayabhaskar A K Sent: Friday, October 31, 2003 10:16 AM To: dhcwg@ietf.org Subject: [dhcwg] IDs on remote boot support for DHCP Hi All I am attaching two new drafts dealing with remote boot support for DHCP. I could not submit the draft to ID queue, as the deadline has crossed. Please go through these drafts and let me know your comments. The abstract of these drafts are given below * The Extended Remote Boot Option for DHCPv4 Single TFTP server for huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. Moreover, some of the clients need multiple bootfiles for boot up. This document provides a new DHCPv4 option for clients to obtain information about multiple TFTP servers and bootfiles. * DHCPv6 Support for Remote Boot This document provides new DHCPv6 (Dynamic Host Configuration protocol version 6) options for clients, to obtain information about TFTP servers and bootfiles needed for booting. Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 05:05:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28905; Wed, 5 Nov 2003 05:05:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKXG-0006O0-AR; Wed, 05 Nov 2003 05:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKWT-0006NU-8Q for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 05:04:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28887 for ; Wed, 5 Nov 2003 05:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKWP-0000bw-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 05:04:17 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHKWO-0000bo-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 05:04:16 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hA59lVg16458; Wed, 5 Nov 2003 16:47:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hA59l9T21972; Wed, 5 Nov 2003 16:47:09 +0700 (ICT) From: Robert Elz To: SENTHIL KUMAR BALASUBRAMANIAN cc: dhcwg@ietf.org, pbpatel@india.hp.com Subject: Re: [dhcwg] ID on Proxy Server Configuration using DHCP In-Reply-To: <200311042029.BAA06679@iconsrv5.india.hp.com> References: <200311042029.BAA06679@iconsrv5.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Nov 2003 16:47:09 +0700 Message-ID: <21479.1068025629@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is the kind of option that has been needed for ages. I'd be interested in knowing if it is likely that any clients (browsers in particular) are likely to support it, or what would be needed for them to support it - the option will be useless if it isn't used. I'll leave the DHCP details for someone more expert in DHCP than I to comment on - though my impression is that most proxy configuration is done using a URL format, and I'd wonder if perhaps the config that is wanted for a proxy shouldn't be a URL, rather than a binary address & port number. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 10:18:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09587; Wed, 5 Nov 2003 10:18:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPQ1-0007Y0-2D; Wed, 05 Nov 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPPO-0007VC-P9 for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 10:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09493 for ; Wed, 5 Nov 2003 10:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPPM-0005c9-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 10:17:20 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AHPPM-0005c6-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 10:17:20 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id D9E0B1C02223; Wed, 5 Nov 2003 07:17:16 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id UAA21122; Wed, 5 Nov 2003 20:45:57 +0530 (IST) From: "Vijayabhaskar A K" To: "'Bernie Volz'" Cc: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Wed, 5 Nov 2003 20:47:06 +0530 Message-ID: <000001c3a3af$e336a780$38e62a0f@nt23056> 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.4024 Importance: Normal In-Reply-To: <000001c3a352$1923acc0$6401a8c0@BVolz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie Thanks for your comments. My reply inline.. Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Bernie Volz > Sent: Wednesday, November 05, 2003 9:36 AM > To: 'Vijayabhaskar A K' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > > Vijay: > > I don't understand the suboption (1) encoding for the > multiple servers (ts > field) and the bootfiles (fn fields). Perhaps something > happened with this document or it is incomplete? No. There is no problem with the draft. Option 66 and 67 are are used as suboption to the suboption (1). Thus, 2 levels of suboptions are used here.. The parsing of these suboptions should be done similar to the other suboptions.. >Please look > it over. Perhaps it is my problem, but if it isn't clear, I'm > sure others will have similar issues. Why don't you just use > two suboptions, one for the list of TFTP servers to use and > another for the bootfile names? I want to associate files with the tftp servers.. If I define them as you have suggested, the servers and files will be disjoint.. > Also, can the TFTP server > names be IP addresses? Yes. It's a nice idea. A new suboption (op code: 1) can be defined for Remote Boot Information suboption to carry a tftp server address. Either this option or option 66 can appear in the ts field... > Perhaps you should consider using the > DNS wire format instead of ASCII? Both can co-exist with the model defined above.. > > I have a similar issue with the DHCPv6 draft. Seems to me if > makes more sense to have two options - one to list the TFTP > servers and another to list the bootfiles? (I guess there > could be an argument made that different bootfiles might be > used with different servers???) Same reason as that of DHCPv4 > It is also odd that you would > want to allow multiple TFTP server addresses in the DHCPv4 > case, but only allow one in the DHCPv6 case. Or have I missed > something? Section 5 says: This option can only appear in the OPTION_REMOTE_BOOT. If multiple Remote Boot Parameters Options are present in OPTION_REMOTE_BOOT, then they should be listed in the increasing order of preferences. Doesn't this convey that mutiple tftp servers can be sent? OPTION_REMOTE_BOOT can encapsulate mutiple OPTION_REMOTE_BOOT_PARAMS, which inturn contain a tftp server address and one or more boot files.. Thus OPTION_REMOTE_BOOT can carry multiple boot server addresses and associated boot files... > One way around this problem might be to allow > multiple OPTION_REMOTE_BOOT and for each of these, one can > have a list of server (OPTION_REMOTE_BOOT_SERVERS) and one or > more boot files (OPTION_REMOTE_BOOT_FILES). For each > instances of the OPTION_REMOTE_BOOT, the servers would all > use the same boot files. However, if you want servers to use > different boot files, you simply specify multiple OPTION_REMOTE_BOOTs. The same thing can be achieved using my design with the additional advantages of conveying preference of one tftp server over the other. > > - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 10:21:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09738; Wed, 5 Nov 2003 10:21:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPSu-0007qp-MT; Wed, 05 Nov 2003 10:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPGz-0006uW-Kc for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 10:08:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08568 for ; Wed, 5 Nov 2003 10:08:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPGx-0005VS-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 10:08:39 -0500 Received: from mbiaemail.mbiabattery.com ([216.248.169.121]) by ietf-mx with smtp (Exim 4.12) id 1AHPGx-0005V4-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 10:08:39 -0500 Received: by mbiaemail.mbiabattery.com (Postfix, from userid 65534) id D402E40C4C; Wed, 5 Nov 2003 10:13:58 -0500 (EST) Received: from D11Q2T21 (unknown [10.1.20.135]) by mbiaemail.mbiabattery.com (Postfix) with ESMTP id B396C40932 for ; Wed, 5 Nov 2003 10:13:58 -0500 (EST) Reply-To: From: "Larry Lewallen" To: Date: Wed, 5 Nov 2003 10:07:01 -0500 Organization: MBIA-HQ Message-ID: <002501c3a3ae$7aa9c810$8714010a@mbiabattery.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C3A384.91D3C010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,HTML_70_80 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [dhcwg] DHCP Client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C3A384.91D3C010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there a way to tell what workstations have been assigned a particular ip address via DHCP? ------=_NextPart_000_0026_01C3A384.91D3C010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a way to tell what workstations have been = assigned a particular ip address via DHCP?

------=_NextPart_000_0026_01C3A384.91D3C010-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 14:33:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19052; Wed, 5 Nov 2003 14:33:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTOm-00078X-9x; Wed, 05 Nov 2003 14:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTO9-00077P-Cp for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 14:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18985 for ; Wed, 5 Nov 2003 14:32:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTO6-0001SK-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 14:32:18 -0500 Received: from smtp003.mail.ukl.yahoo.com ([217.12.11.34]) by ietf-mx with smtp (Exim 4.12) id 1AHTNy-0001RM-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 14:32:10 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 5 Nov 2003 19:31:36 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] ID on Proxy Server Configuration using DHCP Date: Wed, 5 Nov 2003 11:31:03 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200311042029.BAA06679@iconsrv5.india.hp.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think this proposed option and set of sub-options is both unnecessary and unlikely to be used. I base my opinion on the existence of three current DHCP options that are not, to my knowledge, used at all: option 72 -- Default World Wide Web (WWW) Server option 73 -- Default Finger Server option 74 -- Default Internet Relay Chat (IRC) Server To be sure of my position, I configured two of the most widely used DHCP servers with option 72 data, then released existing DHCP leases and rebooted hosts using two different DHCP clients and two different web browsers, monitoring the data exchange with Ethereal. Neither client requested option 72 from the server and neither server sent the option without being requested. When the web browsers were started, neither one issued a DHCPINFORM message requesting option 72. Perhaps someone could come forward with a justification for these three options? Of course the DHC Working Group could define a means for configuring a client with proxy server information, but I fear it would be like options 72, 73, and 74 -- unused. The key to success is to have DHCP client vendors as well as applications vendors committed to using the option and sub-options if the DHC Working Group were to define them. I also object to this wording, found in section 4 of the draft: "More than one Sub Option MAY be specified for the same protocol. In that case, the precedence MUST be given in the order in which these options were received by the client. The first one received shall be given higher priority and so on." I know of no other DHCP option in which the order of receipt mandates the priority for use by the client, and I don't think this is a good precedent to establish without a compelling reason to do so. Consider the routers (03) option: "The router option specifies a list of IP addresses for routers on the client's subnet. Routers SHOULD be listed in order of preference." There is only a recommendation ("SHOULD") that a client receiving this option choose which router to use for subsequent IP messages according to the order of appearance in the router option. A client is free to choose whichever router it wishes for future messages, possibly applying some other information in making the choice. I believe this is a very good model to follow. "Security Considerations," section 8, contains this statement: "The DHCP Options defined here allow an unauthorized DHCP server to misdirect a client to access nonexistent/erring Proxy Server due to which the connection to the Internet might be denied." Yes, but every other option presents an opportunity to misconfigure a client, either unintentionally or maliciously. The word "unauthorized" implies that there is such a thing as an "authorized" DHCP server, which is both incorrect and misleading. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 16:25:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24671; Wed, 5 Nov 2003 16:25:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8c-0005bM-CS; Wed, 05 Nov 2003 16:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV3t-00054G-0Y for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 16:19:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24179 for ; Wed, 5 Nov 2003 16:19:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHV3r-0003Up-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 16:19:31 -0500 Received: from smtp002.mail.ukl.yahoo.com ([217.12.11.33]) by ietf-mx with smtp (Exim 4.12) id 1AHV3q-0003Uh-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 16:19:30 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 5 Nov 2003 21:18:59 -0000 Reply-To: From: "Barr Hibbs" To: "Vijayabhaskar A K" , Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Wed, 5 Nov 2003 13:18:26 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000b01c39fc1$db186760$38e62a0f@nt23056> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > * The Extended Remote Boot Option for DHCPv4 > > Single TFTP server for huge number of diskless clients is prone > to single point of failure. So, Multiple TFTP servers are needed for > high availability. Moreover, some of the clients need multiple > bootfiles for boot up. This document provides a new DHCPv4 option > for clients to obtain information about multiple TFTP servers and > bootfiles. > First, I'd like to clarify the precedence of DHCP options and fields: order option or field name ------- ----------------------------- highest proposed Extended Remote Boot medium options 66 and 67 lowest 'sname' and 'fname' Does my understanding match the intent of this draft? If so, I'd like to see a clarification to RFC 2132 options 66 and 67 in this draft, as well as wording to make the precedence unequivocal. Second, although options 66 and 67 were intended to simply provide a way to represent the contents of the BOOTP 'sname' and 'fname' fields in options, I question the appropriateness of using a name rather than IP address for the server: in other words, I'd like to see option 66 changed to use IP address rather than name to identify the server, and I'd also like to see the same convention used in this draft. I'll go even further and strongly suggest that we deprecate options 66 and 67 and have only a single [new] Extended Remote Boot option to replace them. I'm not sure that I agree that file name(s) should be coupled to a specific server name: shouldn't the boot file name(s) be identical for all servers that offer the remote bootstrap service? There is an implicit understanding with all other options offering multiple servers (for example, DNS servers) that the data offered by each server identified in a multiple option is essentially identical to every other identified server. Coupling file name(s) to server name seems to invalidate this concept. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 16:45:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25530; Wed, 5 Nov 2003 16:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVSZ-0000HK-17; Wed, 05 Nov 2003 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVRt-0000Gf-Lb for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 16:44:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25446 for ; Wed, 5 Nov 2003 16:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVRr-0003xv-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 16:44:19 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AHVRr-0003xs-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 16:44:19 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hA5LiAGn024201; Wed, 5 Nov 2003 16:44:19 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , "'Vijayabhaskar A K'" , Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Wed, 5 Nov 2003 16:44:16 -0500 Message-ID: <000001c3a3e5$f8cd53b0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable If a DNS name is used for the TFTP server, that name could resolve into several addresses and therefore some level of failover/redundancy is possible (even today) - provided of course that the TFTP client is set = up to support this. I agree that using IP addresses is better, as this = information may be needed at an early stage when a DNS resolver may not be available (the DHCP server could do the DNS lookup). There is an argument that the boot file names might be different on TFTP servers - for example, the paths where the files are located could be different. Though I would expect this to be rare? I agree that clarifying the precedence is important. RFC 2132 says: This option is used to identify a TFTP server when the 'sname' field in the DHCP header has been used for DHCP options. A similar statement exists for the bootfile name. So, I suspect that = this implies that both are not allowed. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Wednesday, November 05, 2003 4:18 PM To: Vijayabhaskar A K; dhcwg@ietf.org Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > * The Extended Remote Boot Option for DHCPv4 > > Single TFTP server for huge number of diskless clients is prone > to single point of failure. So, Multiple TFTP servers are needed for > high availability. Moreover, some of the clients need multiple > bootfiles for boot up. This document provides a new DHCPv4 option > for clients to obtain information about multiple TFTP servers and > bootfiles. > First, I'd like to clarify the precedence of DHCP options and fields: order option or field name ------- ----------------------------- highest proposed Extended Remote Boot medium options 66 and 67 lowest 'sname' and 'fname' Does my understanding match the intent of this draft? If so, I'd like = to see a clarification to RFC 2132 options 66 and 67 in this draft, as well = as wording to make the precedence unequivocal. Second, although options 66 and 67 were intended to simply provide a way = to represent the contents of the BOOTP 'sname' and 'fname' fields in = options, I question the appropriateness of using a name rather than IP address for = the server: in other words, I'd like to see option 66 changed to use IP = address rather than name to identify the server, and I'd also like to see the = same convention used in this draft. I'll go even further and strongly suggest that we deprecate options 66 = and 67 and have only a single [new] Extended Remote Boot option to replace = them. I'm not sure that I agree that file name(s) should be coupled to a = specific server name: shouldn't the boot file name(s) be identical for all = servers that offer the remote bootstrap service? There is an implicit = understanding with all other options offering multiple servers (for example, DNS = servers) that the data offered by each server identified in a multiple option is essentially identical to every other identified server. Coupling file name(s) to server name seems to invalidate this concept. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 17:22:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27183; Wed, 5 Nov 2003 17:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHW2L-0002Rg-9x; Wed, 05 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHW1w-0002RT-HA for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 17:21:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27134 for ; Wed, 5 Nov 2003 17:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHW1u-0004fx-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 17:21:34 -0500 Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35]) by ietf-mx with smtp (Exim 4.12) id 1AHW1t-0004fD-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 17:21:33 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 5 Nov 2003 22:21:02 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Wed, 5 Nov 2003 14:20:30 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000001c3a3e5$f8cd53b0$6401a8c0@BVolz> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit comments inline --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Bernie Volz > Sent: Wednesday, November 05, 2003 13:44 > > If a DNS name is used for the TFTP server, that name could resolve into > several addresses and therefore some level of failover/redundancy is > possible (even today) - provided of course that the TFTP client > is set up to support this. I agree that using IP addresses is better, > as this information may be needed at an early stage when a DNS resolver > may not be available (the DHCP server could do the DNS lookup). > ...Bernie, you're right about the built-in redundancy of multiple resolutions of a TFTP server name to IP address, but as far as I recall, this is the only DHCP option (66) that uses a host name instead of IP address for reference to a network resource. Besides, if multiple servers are identified, then the need for host name to host address transformations to provide redundancy is a moot issue. > There is an argument that the boot file names might be different on TFTP > servers - for example, the paths where the files are located could be > different. Though I would expect this to be rare? > ...again, yes, this is true, but we have to ask ourselves how likely this will be? Maybe we should poll the mailing list and known vendors? I tend to favor the position of most flexibility, but only if justified, and would strongly suggest a means to say, "the following list of file names is identical for all servers," saving a considerable amount of options space in the DHCPACK packet. I'd like to point out that there is no requirement that a client would use the TFTP boot server information in any specific state, although I can't imagine a client requesting the information would not use it in the INIT state, and probably also the INIT-REBOOT state. As I read RFC 2132, it's not clear to me how options 66 and 67 are actually used: with BOOTP (and DHCP without overloading the 'sname' and 'fname' fields) the server would apparently fill-in both fields if it had been configured with the data for the particular client requesting an address, but what about options 66 and 67? If configured with remote boot information AND the 'sname' and 'fname' fields ARE overlaid, should the server insert these options without being requested? I'll add this to the list of clarifications needed for RFC 2131. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 18:49:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01668; Wed, 5 Nov 2003 18:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXOY-0007v5-6D; Wed, 05 Nov 2003 18:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXOJ-0007un-Ol for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 18:48:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01649 for ; Wed, 5 Nov 2003 18:48:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXOG-00060N-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 18:48:44 -0500 Received: from smtp001.mail.ukl.yahoo.com ([217.12.11.32]) by ietf-mx with smtp (Exim 4.12) id 1AHXOF-0005zs-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 18:48:43 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 5 Nov 2003 23:48:12 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface Information Option Date: Wed, 5 Nov 2003 15:47:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > -- DHCP Discovery Extensions -- > > This draft defines simple protocol enhancements to DHCP so that it > can be used for the following applications: > > - Discovery of clients in the network > - DHCP server redundancy > - Server-initiated configuration of clients > > It allows server-initiated communication to specific or all clients > in the network, using the DHCP packet format. Other DHCP servers > in the network can be provided with information about all > existing client configurations and will therefore be able to take > over if the main server fails. > ...I object to this draft for several reasons: 1. it alters the fundamental nature of DHCP protocol exchanges from client-initiated to server-initiated (RFC 3203 notwithstanding, as there are no known implementations of RFC 3203.) 2. it seems to require that the basic model of server operation be changed from stateless to stateful with respect to DHCP clients 3. it specifies the collection and maintenance of configuration data about it's clients that appears to significantly increase the amount of stable storage required of a server 4. it has the potential to trigger broadcast storms through what I view as ill-considered transmission of broadcast packets to potentially tens or hundreds of thousands of clients, each packet requesting another broadcast packet in response 5. it overrides the expected default behavior of DHCP servers -- that a server never (well, almost never) sends an unrequested option to a client 6. it mandates that a client IP stack and DHCP client software be at least partially operational before the DHCP client has fully initialized the IP stack -- a window of opportunity that is in almost every conceivable case less than 64 seconds, and largely less than 2-4 seconds, hardly a compelling argument for the extra complexity and functionality 7. it apparently mandates the use of option 61, client identifier, which is optional per RFC 2131 8. it requires a DHCP client to adopt a new state machine to allow for forced configuration changes using the DHCPCONFIGURE message, but does not specify state transitions 9. it requires a client to respond to a DHCPCONFIGURE message with a DHCPRELEASE message, followed by a DHCPREPORT message, but does not discuss side-effects of such behavior: for example, if a client had previously dynamically updated a DNS server with it's IP address information, it presumably MUST also update DNS after a DHCPCONFIGURE message forces a new IP address on the client 10. it's not clear that some network elements such as switches will even be able to forward packets to clients before the client initiates the RFC 2131 message exchange -- many switches do not keep a port open for an uninitialized client > > -- DHCP Interface Information Option -- > > This draft defines a new option to inform the server about > the client's physical interface it is connected to. > This information may be used together with the relay agent > information option (RFC 3046) for the purpose of topology > recognition. > ...this draft presumes a mode of operation for a DHCP server which is not compatible with RFC 2131, namely that it calls for the server to send an [unrequested by the client] option code to the client in the parameter request list that requires a response from the client to the server. This might better be a sub option for the Relay Agent Information Option, to be added by Relay Agents so equipped for packets forwarded towards the server. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 18:57:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02014; Wed, 5 Nov 2003 18:57:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXWH-00006t-HG; Wed, 05 Nov 2003 18:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXVj-00005B-93 for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 18:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01982 for ; Wed, 5 Nov 2003 18:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXVf-00066Z-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 18:56:24 -0500 Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35]) by ietf-mx with smtp (Exim 4.12) id 1AHXVf-000665-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 18:56:23 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 5 Nov 2003 23:55:53 -0000 Reply-To: From: "Barr Hibbs" To: "Rentschler, Markus" , "Kostur, Andre" , Subject: RE: [dhcwg] ID's: Interface Information Option Date: Wed, 5 Nov 2003 15:55:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Regarding: DHCP Interface Information Option > > - According to RFC 2131, a DHCP Server MUST NOT supply a Parameter > Request List option to a client (in OFFER, ACK, or NAK), thus a server > cannot request this option. > > [MR>] Ok. Then a client that has multiple interfaces SHOULD always > send the Interface Information Option to the server, without any request. > That wouldn't violate the restriction you've mentioned. > > Apart from that: I cannot see any useful reason for that > restriction, since it limits the potential of DHCP. > Any idea what might be the background of that restriction ? > ...there is NO requirement that a server do anything with options sent to it that are not necessary for its primary purpose of configuring a client. So, for example, if a client sends the "Default WWW Server" option, the server is free to ignore it, report it, or record it, all according to the implementation and local administrative decision. As far as the restriction on the Parameter Request List from server to client, it's because the role of the server is to respond to requests from the client (ignoring RFC 3202 for the moment as it has no known implementations,) NOT the other way round. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 19:09:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02468; Wed, 5 Nov 2003 19:09:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXht-00010p-O1; Wed, 05 Nov 2003 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXhj-00010W-OL for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 19:08:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02421 for ; Wed, 5 Nov 2003 19:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXhg-0006HG-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 19:08:48 -0500 Received: from smtp001.mail.ukl.yahoo.com ([217.12.11.32]) by ietf-mx with smtp (Exim 4.12) id 1AHXhf-0006H5-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 19:08:47 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 6 Nov 2003 00:08:17 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Wed, 5 Nov 2003 16:07:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Rentschler, Markus > Sent: Tuesday, November 04, 2003 01:29 > > > Regarding: DHCP Discovery Extensions > > > > - I think there's some overlap here. What's different between a > > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) (Functionally speaking). > > Both of them cause a device to acquire new configuration information. > [MR>] > To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must already > have a lease assigned! > With the Discovery Extensions I try to overcome this. > It's in fact a different philosophy to "traditional" DHCP, even a > different protocol, that just uses the DHCP packet format and the DHCP > infrastructure!! This point must be clearly understood. > ...overlaying a different protocol onto the message formats of another protocol sometimes has great value, as with DHCP being effectively a superset of BOOTP functionality, but this I-D specifies such radically different behavior that I just have to say that I think it is a very bad idea to proceed with its development. Having said that, the existence of the draft, apparently to satisfy the perceived need of a network administrator to tightly control all aspects of client configuration points out that the DHC Working Group probably ought to consider a work item to study more proactive functionality. > Right now there are some proprietary Discovery Protocols under > development by some industry consortiums that go into that direction. > But I don't want yet another proprietary packet format and protocol > infrastructure if I can easily adopt DHCP, which does familiar things > anyway. Thats the background of my draft. > ...funny thing about proprietary protocols: some become de facto standards (as SNA was for IBM-centric computing environments at one time) but most haven't survived without the support of a diverse group of vendors and users. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 19:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03314; Wed, 5 Nov 2003 19:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYIe-0003G6-Rx; Wed, 05 Nov 2003 19:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYIS-0003F9-8M for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 19:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03296 for ; Wed, 5 Nov 2003 19:46:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHYIQ-0006jX-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 19:46:46 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AHYIP-0006jU-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 19:46:45 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 4134A1B209E; Wed, 5 Nov 2003 18:40:34 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] ID's: DHCP Discovery Extensions Date: Wed, 5 Nov 2003 18:46:43 -0600 To: X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > ...overlaying a different protocol onto the message formats of another > protocol sometimes has great value, as with DHCP being effectively a > superset of BOOTP functionality, but this I-D specifies such radically > different behavior that I just have to say that I think it is a very > bad > idea to proceed with its development. Having said that, the existence > of This I agree with. This protocol is really a different animal than DHCP, and I don't think it benefits from relay agent functionality. I'd say that, first of all, if you need a relay agent, it probably wants to be a different relay agent - a relay agent to support this protocol is more different than a DHCP relay agent than it is similar to a DHCP relay agent. And secondly, I have trouble imagining how you'd get vendors to put a relay agent of this type in their devices, even if you could come up with a working protocol. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 5 22:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07799; Wed, 5 Nov 2003 22:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHaen-0004B2-FM; Wed, 05 Nov 2003 22:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHadt-0004Aj-4r for dhcwg@optimus.ietf.org; Wed, 05 Nov 2003 22:17:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07763 for ; Wed, 5 Nov 2003 22:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHadp-0000rv-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 22:17:01 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AHadp-0000rs-00 for dhcwg@ietf.org; Wed, 05 Nov 2003 22:17:01 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hA63GsGn067128 for ; Wed, 5 Nov 2003 22:17:02 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Wed, 5 Nov 2003 22:17:02 -0500 Message-ID: <000001c3a414$757d8f50$6401a8c0@BVolz> 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.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I also agree that this should not be adopted as a WG item or advance. If this capability is truly needed, a separate protocol should be developed. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, November 05, 2003 7:47 PM To: rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: Re: [dhcwg] ID's: DHCP Discovery Extensions > ...overlaying a different protocol onto the message formats of another > protocol sometimes has great value, as with DHCP being effectively a > superset of BOOTP functionality, but this I-D specifies such radically > different behavior that I just have to say that I think it is a very > bad > idea to proceed with its development. Having said that, the existence > of This I agree with. This protocol is really a different animal than DHCP, and I don't think it benefits from relay agent functionality. I'd say that, first of all, if you need a relay agent, it probably wants to be a different relay agent - a relay agent to support this protocol is more different than a DHCP relay agent than it is similar to a DHCP relay agent. And secondly, I have trouble imagining how you'd get vendors to put a relay agent of this type in their devices, even if you could come up with a working protocol. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 00:36:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11613; Thu, 6 Nov 2003 00:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHcoM-0002aQ-Cy; Thu, 06 Nov 2003 00:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHcnw-0002Zr-Co for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 00:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11588 for ; Thu, 6 Nov 2003 00:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHcnt-0002bp-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 00:35:33 -0500 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 1AHcns-0002bm-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 00:35:33 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 05:35:33 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Wed, 5 Nov 2003 21:35:01 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <011601c39764$a6e9cd90$b7cbdba8@daniel> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Daniel, Bernie-- is there sufficient demand for a DHCPv4 solution to highly mobile devices that this option is necessary? I don't object to this proposed option, but I do wonder if a DHCPv4 solution is merely a stopover on the road to DHCPv6? Is there any benefit to somehow restricting its use to avoid a large-scale migration from the Discover-Offer-Request-Ack cycle to the abbreviated exchange? Should we be developing what I see as an alternative to Mobile-IP? I'd like to see an updated client state transition diagram showing this exchange and updated message required field and option content tables covering the DHCPDISCOVER and DHCPACK message changes when you update the draft. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 01:34:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12992; Thu, 6 Nov 2003 01:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHdiT-0004v6-Gs; Thu, 06 Nov 2003 01:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHdi7-0004us-Q8 for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 01:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12967 for ; Thu, 6 Nov 2003 01:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHdi4-0003Go-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 01:33:36 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AHdi4-0003Gl-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 01:33:36 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 4EE1D1C00CDF; Thu, 6 Nov 2003 01:33:34 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id MAA22591; Thu, 6 Nov 2003 12:02:17 +0530 (IST) From: "Vijayabhaskar A K" To: , Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Thu, 6 Nov 2003 12:03:24 +0530 Message-ID: <004201c3a42f$e2e59220$38e62a0f@nt23056> 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.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Barr Thanks for your comments.. My commments inline.. > -----Original Message----- > From: Barr Hibbs [mailto:rbhibbs@pacbell.net] > Sent: Thursday, November 06, 2003 2:48 AM > To: Vijayabhaskar A K; dhcwg@ietf.org > Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > > > > > * The Extended Remote Boot Option for DHCPv4 > > > > Single TFTP server for huge number of diskless clients is prone to > > single point of failure. So, Multiple TFTP servers are needed for > > high availability. Moreover, some of the clients need multiple > > bootfiles for boot up. This document provides a new DHCPv4 > option for > > clients to obtain information about multiple TFTP servers and > > bootfiles. > > > > First, I'd like to clarify the precedence of DHCP options and fields: > > order option or field name > ------- ----------------------------- > highest proposed Extended Remote Boot > medium options 66 and 67 > lowest 'sname' and 'fname' > > Does my understanding match the intent of this draft? If so, > I'd like to see a clarification to RFC 2132 options 66 and 67 > in this draft, as well as wording to make the precedence unequivocal. Yes, you are correct. I will add appropriate text.. > > Second, although options 66 and 67 were intended to simply > provide a way to represent the contents of the BOOTP 'sname' > and 'fname' fields in options, I question the appropriateness > of using a name rather than IP address for the > server: in other words, I'd like to see option 66 changed to > use IP address rather than name to identify the server, and > I'd also like to see the same convention used in this draft. I agree with you that dns name is not very appropriate here.. Since, RFC 2131 defines sname as name and the representation of tftp server as name is deployed and widely used in many bootp servers without any complaints, I really didn't want to change the widely used model... But, the provision to represent tftp server as IP address can be added.. A new suboption (op code: 1) can be defined for Remote Boot Information suboption to carry a tftp server address. Either this option or option 66 can appear in the ts field... > > I'll go even further and strongly suggest that we deprecate > options 66 and 67 and have only a single [new] Extended > Remote Boot option to replace them. Yes, I strongly recommend that.. > > I'm not sure that I agree that file name(s) should be coupled > to a specific server name: shouldn't the boot file name(s) > be identical for all servers that offer the remote bootstrap > service? The one reason I could think of is, as bernie told, the path may be different in different servers.. I believe, there is nothing wrong in keeping in providing this flexibility... In the case, where the file names are same, the provision can be made in this option to specify only the tftp server/name and take the file names from its previous Remote Boot Information suboption, which has the file names.. In this way, we can keep both the flexibility and the save space in the bootp message.. > There is an implicit understanding with all other > options offering multiple servers (for example, DNS servers) > that the data offered by each server identified in a multiple > option is essentially identical to every other identified > server. I guess, you are talking about DNS server addresses and the domain name.. In the most of the cases, the domain name will be unique on the link, even we can say, it will be unique on the site.. If not, atleast all the bootp server should be configured to give the same domain name for *this* client.. Similar case for NIS, NIS+ and NetBIOS.. Apart from this, I could not see any relationship in any other options.. Here, the boot file option is altogether different and the client needs just a file and the location of the file is not an issue.. the location MAY vary on different tftp servers.. > Coupling file > name(s) to server name seems to invalidate this concept. The coupling was not needed till now, because, we provide only a single tftp server and file name.. Now, there is a need for it.. > > --Barr > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 03:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27798; Thu, 6 Nov 2003 03:03:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHf6b-0003Eo-2e; Thu, 06 Nov 2003 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHf5q-0003E0-5Y for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 03:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27749 for ; Thu, 6 Nov 2003 03:02:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHf5m-0004QN-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 03:02:10 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AHf5l-0004Pi-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 03:02:09 -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 <0HNX0051C7MRJI@mailout2.samsung.com> for dhcwg@ietf.org; Thu, 06 Nov 2003 17:01:39 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNX004JM7MD92@mailout2.samsung.com> for dhcwg@ietf.org; Thu, 06 Nov 2003 17:01:26 +0900 (KST) Received: from LocalHost ([165.213.91.136]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNX00IY37MDTA@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 06 Nov 2003 17:01:25 +0900 (KST) Date: Thu, 06 Nov 2003 17:01:27 +0900 From: Ron Lee Subject: [dhcwg] DHCPv6 server availability To: dhcwg@ietf.org Message-id: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello, I am wondering which companies have implemented DHCPv6 server. I know there are 6 major vendors who participated in the conformance testing in the past July IETF meeting, but I cannot find the result. Any related information is greatly appreciated. Thanks. ========================================================== Ron Lee Senior Engineer Telecommunication Division, Samsung Electronics Co., Ltd Suwon, South Korea _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 04:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00264; Thu, 6 Nov 2003 04:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgN6-0007ec-RF; Thu, 06 Nov 2003 04:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfHl-0004Ew-91 for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 03:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28158 for ; Thu, 6 Nov 2003 03:14:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfHi-0004ZJ-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 03:14:30 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AHfHi-0004Z8-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 03:14:30 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119043>; Thu, 6 Nov 2003 09:06:32 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Nov 2003 09:10:41 +0100 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Subject: WG: [dhcwg] ID's: Interface Information Option Date: Thu, 6 Nov 2003 09:10:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > [MR>] Hi, > =20 > Assuming that a client SHOULD always send the IIO to the server, what = does > it fill it with in the original Discover? At this point it has never > recieved a Server->Client packet. > [MR>] Clients wouldn't be able provide the IIO at this time. They = need at > least one packet received from the server to determine the receiving > interface. The IIO can therefore only be added to responses to the = server, > not to initial client messages. But since there is a four message = exchange > with DHCP, the client will always have the opportunity to get the IIO = to > the server. >=20 > What benefit does this particular option give over simply using the > existing Client Identifier (Opt 61) to encode such information?=20 > [MR>] There are several benefits: >=20 > -- Another parameter for more tightly IP address allocation schemes = for > higher security. (The server configurator can for example say: a = certain > IP address/configuration is only allowed to a certain client (use MAC = and > /or Client-Id) on a certain location in the network topology (use = Option > 82) that is connected via a certain interface (use IIO). > Any other useful combinations with other client's parameter as = trigger > conditions may be thought of... > -- Possibility for topology discovery and therefore detection of > misconfigured connections. >=20 (Which still doesn't address what happens on the original Discover)=20 [MR>] =20 > You note in section 1:=20 >=20 > The relay agent information option [RFC 3046], which is added by=20 > a relay agent to a client's request to the server, contains in its = > Circuit ID sub option the number of the physical interface on = which=20 > the relay received this client's request..=20 >=20 > Keep in mind that devices using opt 82 aren't required to have a = circuit > ID. The wording of the above should reflect that a device MAY add a > circuit ID. =20 > [MR>] That's correct. I will change that. >=20 > As well, the service cannot assume what the contents of a Circuit ID > represents. > [MR>] "ecxact string match" (as in RFC 3046 for the Circuit-ID) is = also > required for the IIO. >=20 > Regards, > Markus >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Kostur, Andre [SMTP:Andre@incognito.com] > Gesendet am: Dienstag, 4. November 2003 18:14 > An: 'Rentschler, Markus'; dhcwg@ietf.org > Betreff: RE: [dhcwg] ID's: Interface Information Option _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 05:23:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02931; Thu, 6 Nov 2003 05:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhI4-0005Vn-T8; Thu, 06 Nov 2003 05:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhHe-0005QM-Ue for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 05:22:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02901 for ; Thu, 6 Nov 2003 05:22:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhHb-0006WY-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 05:22:31 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AHhHb-0006WS-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 05:22:31 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 60ED21C005A3; Thu, 6 Nov 2003 02:22:05 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA11892; Thu, 6 Nov 2003 15:50:46 +0530 (IST) From: "Vijayabhaskar A K" To: "'Ron Lee'" , Subject: RE: [dhcwg] DHCPv6 server availability Date: Thu, 6 Nov 2003 15:51:54 +0530 Message-ID: <004a01c3a44f$cfbda5f0$38e62a0f@nt23056> 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.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HPUX had implemented dhcpv6 server, but its based on 16th version of the internet draft and rfc 3315 supersedes 28th version, so its is pretty older.. Anyhow, you can download it freely through http://software.hp.com Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ron Lee > Sent: Thursday, November 06, 2003 1:31 PM > To: dhcwg@ietf.org > Subject: [dhcwg] DHCPv6 server availability > > > > Hello, I am wondering which companies have implemented DHCPv6 > server. I know there are 6 major vendors who participated in > the conformance testing in the past July IETF meeting, but I > cannot find the result. > > Any related information is greatly appreciated. > Thanks. > > ========================================================== > Ron Lee > Senior Engineer > > Telecommunication Division, > Samsung Electronics Co., Ltd > Suwon, South Korea > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 08:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07807; Thu, 6 Nov 2003 08:25:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk8E-00069s-4e; Thu, 06 Nov 2003 08:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk7j-000694-0G for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 08:24:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07777 for ; Thu, 6 Nov 2003 08:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHk7h-0000vN-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 08:24:29 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AHk7h-0000v0-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 08:24:29 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119051>; Thu, 6 Nov 2003 14:16:39 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Nov 2003 14:20:50 +0100 Message-ID: From: "Rentschler, Markus" To: rbhibbs@pacbell.net, dhcwg@ietf.org Subject: AW: [dhcwg] ID's: Interface Information Option Date: Thu, 6 Nov 2003 14:20:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > ...there is NO requirement that a server do anything with options = sent to > it > that are not necessary for its primary purpose of configuring a = client. > So, > for example, if a client sends the "Default WWW Server" option, the = server > is free to ignore it, report it, or record it, all according to the > implementation and local administrative decision. [MR>]=20 That's correct. The same will be the case with the IIO. The server is free to use it or not, that depends entirely on the server implementation. > As far as the restriction on the Parameter Request List from server = to > client, it's because the role of the server is to respond to requests = from > the client (ignoring RFC 3202 for the moment as it has no known > implementations,) NOT the other way round. [MR>] =20 This is also true. But I see it as a potential limitation, not as a necessary restriction. It reduces flexibility of the protocol (just my humble opinion). > --Barr >=20 -----Urspr=FCngliche Nachricht----- Von: Barr Hibbs [SMTP:rbhibbs@pacbell.net] Gesendet am: Donnerstag, 6. November 2003 00:55 An: Rentschler, Markus; Kostur, Andre; dhcwg@ietf.org Betreff: RE: [dhcwg] ID's: Interface Information Option Best Regards, Markus _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 08:46:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08618; Thu, 6 Nov 2003 08:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkSX-0007dA-CO; Thu, 06 Nov 2003 08:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkRc-0007bb-2m for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 08:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08568 for ; Thu, 6 Nov 2003 08:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHkRa-0001BW-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 08:45:02 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AHkRZ-0001BI-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 08:45:01 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119043>; Thu, 6 Nov 2003 14:37:15 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Nov 2003 14:41:25 +0100 Message-ID: From: "Rentschler, Markus" To: "Kostur, Andre" , dhcwg@ietf.org Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions Date: Thu, 6 Nov 2003 14:41:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA08569 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must alread= y=20 > > have a lease assigned!=20 > True, the device must already have a DHCP state machine running. But i= f > there's no state machine running, then the device is choosing to not us= e > DHCP! [MR>]=20 The device should be configurable in terms of DHCP on or off (as are all devices I am aware of).=20 If the Discovery Extensions are supported, the acceptance of DHCPCONFIGURE should be configurable. Additionally initial sending of DHCPDISCOVER should be configurable. > > With the Discovery Extensions I try to overcome this.=20 > > It's in fact a different philosophy to "traditional" DHCP, even= a=20 > > different protocol, that just uses the DHCP packet format and the DHC= P=20 > > infrastructure!! This point must be clearly understood.=20 > So you're trying to say that this draft only pertains to unconfigured > devices? And that DHCP servers should be extended to hold information > about devices that aren't performing DHCP (If it is performing DHCP, th= en > the server will learn about the device when it Discovers....)? =20 [MR>] =20 Yes. The server will learn about devices through discovery: "Hey, there is a device".=20 If the device is registered within the servers configuration everything is fine. If it is not, the admin can be informed ("Hey Admin, there is a unregistered device") or any other appropriate action taken. > (Are we then duplicating effort with other protocols/applications which > deal with the network discovery stuff such as SNMP workstations?) [MR>]=20 Yes and No. The Discovery Extensions allow both configuration AND supervision of the network. It's up to the server, what it wants to use > =20 > > Right now there are some proprietary Discovery Protocols under=20 > > development by some industry consortiums that go into that direction.= =20 > > But I don't want yet another proprietary packet format and > protocol=20 > > infrastructure if I can easily adopt DHCP, which does familiar things= =20 > > anyway. Thats the background of my draft.=20 > OK, but DHCP isn't a device discovery protocol (and IMHO, shouldn't be. [MR>] I think differently here...=20 Everybody how wants to use DHCP as ist is right now is free to use it that way in the future and can disable the Discovery Extensions. They won't get any disadvantage to what they have now.=20 Others who want to use it get a lot of functionality through it.=20 The Discover Extensions would be easy to implement.=20 No additional states in the client's state machine required.=20 I can see only advantages...:-) Designing a completely new protocol for device discovery would create a lot of overhead in the client (memory in small clients !!), and = it would have to interact with DHCP anyway on the configuration level on bot= h the client and the server... > And devices which are configured to be using DHCP will, at some point, > broadcast Discover, at which point the device will be "discovered"). A= nd > there is at least one other "Discovery Protocol" mechanism that would w= ork > almost as well (using existing protocols)... performing ICMP Echos to > determine if there is a device, followed by performing an SNMP Walk on = the > target device. =20 [MR>]=20 This allows only discovery of devices that already have their IP addresses assigned and are reachable on the IP layer! If a device is misconfigured and not reachable through IP, there is no SNMP walk... The Discovery Extensions would allow communication between server and client on the Layer 2, prior to IP address allocation! Conmmunicate w= ith clients that are not reachable through IP is always possible!! > > > - The DHCP Client behaviour talks about an "initially granting > server",=20 > > > what if the device has not yet been granted a lease from any server= ?=20 > > [MR>] See my point above. In that case it is configuration, no= t > reconfiguration!=20 > > Reconfiguration should be restricted to the initially granting > server, but not configuration.=20 >=20 > But then the draft is confusing. The draft talks about an initially > granting server (thus the device already has a lease), and you're talki= ng > about configuration (thus the device has no initially granting server).= ... >=20 [MR>]=20 Both should be possible: configuration AND reconfiguration, as the server pleases... > Sure it's configurable. But your draft sets it up in the default case > that "A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a re= lay > agent's other subnets." (Actually, I just noticed that by default the > draft wants all REPORTs to be broadcast too... so that one DHCPNETSCAN > which is sent across your network results in potentially everybody on y= our > network broadcasting back to you.... now there's an efficient DDoS atta= ck > on your entire DHCP infrastructure!) [MR>] =20 That's correct. That's why it should only be configurable and only be used in closed networks that the administrator wants to tigthly contro= l. The default value is on the server this case !!=20 Again: The operator of the server has the full responsibility of what he is doing! Everything depends on the server implementation, that gives the protocol its flexibility. > > [MR>] "The client MUST omit any parameters it cannot=20 > > provide." (see chapter 5). This should of course also be mentioned in > chapter 3.3.=20 > You may wish to reword that to something along the lines of "these opti= ons > are required to be sent by the client, all other options MAY (MUST?) be > included if the client has pertinent information". [MR>] Good suggestion. ......=20 > > [MR>] First RELEASE then REPORT.=20 > OK, what happens in the case:=20 > 1) Device A sends the RELEASE=20 > 2) Device B Discovers & Requests (since the IP is now available, it was > just released!) the now released IP=20 > 3) Device A REPORTs on that IP=20 > ?=20 [MR>] =20 The REPORT must of course use the new IP assigned with DHCPCONFIGURE, since it is the REPORT's main job to tell the rest of the network that a certain client has a certain configuration. So there shou= ld be no problem. > > > DHCP server redundancy is already covered in the Failover draft.=20 > > [MR>] This is true. But server redundancy is not the=20 > > main purpose of the discovery extension. It's a nice "side-effect" =20 > Not to sound nasty, but if this isn't a purpose of the discovery > extension, why is it stated as a goal of the draft?=20 [MR>]=20 I published the draft to show the possible potential of the discovery extensions and to get some feedback on which of this possibilit= es might be useful and which not.=20 A server implmentation may use the redundancy possibility or not. It's up to the server. But I wouldn't restrict the protocol in a way that usage of this possibility is not allowed.=20 The philosophy of the Discovery Extensions are: "The client provides means that the server can use if he wishes." The client only reacts to actions from the server.=20 > Another general comment about the draft. Offhand I think the > DHCPCONFIGURE message is superfluous when there exists RFC 3203. I don= 't > see anything that that DHCPCONFIGURE does that DHCPRECONFIGURE can't do= .=20 > In the case of an "unconfigured" client, there's nothing that needs to = be > done except wait for the device to naturally Discover. For an already > configured device we can send a FORCERENEW, and the device will > immediately transition to the Renewing state, causing it to perform a > REQUEST/ACK sequence, at which point the device can reconfigure itself > based upon the data in the new ACK packet. [MR>] =20 That's true. But there are the following limitations to the mechanism in RFC 3203: --The client cannot get it's (new) configuration information to other servers for redundancy (as it is possible with a broadcasted DHCPREPORT). -- In the supervising case (the server sends a DHCPNETSCAN to see if all its sheep are still in their right places in the network), using the FROCERENEW mechanism would mean a four message exchange for every client!= ! I don't like this very much since it produces a lot of unneccessary traff= ic. -- And again, there is no way to get informations about unconfigured silent devices.=20 If FORCERENEW would also be able to set a "silent" device to the INIT state, I would be happy with it=20 and DHCPCONFIGURE would indeed be superfluous (though I still dislike the four message exchange, which is unneccessary when the server starts communication). But unfortunately it doesn't. The Discovery Extensions are a different approach, please keep this in mind. One shouldn't compare them too much to client-originated DHCP si= nce they follow different philosophies. Best Regards, Markus -----Urspr=FCngliche Nachricht----- Von: Kostur, Andre [SMTP:Andre@incognito.com] Gesendet am: Dienstag, 4. November 2003 18:57 An: 'Rentschler, Markus'; dhcwg@ietf.org Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 09:26:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10150; Thu, 6 Nov 2003 09:26:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl5G-0001BS-6w; Thu, 06 Nov 2003 09:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl4l-00019q-SM for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 09:25:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10000 for ; Thu, 6 Nov 2003 09:25:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHl4k-0001i1-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 09:25:30 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AHl4j-0001hy-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 09:25:29 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hA6EPLGn006184; Thu, 6 Nov 2003 09:25:29 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Thu, 6 Nov 2003 09:25:30 -0500 Message-ID: <000001c3a471$d7c0eab0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Barr: These are good questions and should be addressed. I don't have any = specific case where the Rapid Reply is really desired. As far as restrictions, I would expect any migration would be slow (because of the large deployed client base) and servers should be configurable as to whether they allow = it to be used - such as in cases where multiple servers exist (though = coupled with failover, this option could be very useful to expedite = configuration). Regarding an updated state diagram and processing description, we should provide that (though there are others that have indicated they'd rather = not have state diagrams). Daniel will present this work at the DHC WG meeting next week and we'll revise the draft with that input and any Mailing List input (such as = yours). This assumes that the general consensus is work should continue on this. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Thursday, November 06, 2003 12:35 AM To: dhcwg@ietf.org Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Daniel, Bernie-- is there sufficient demand for a DHCPv4 solution to highly mobile = devices that this option is necessary? I don't object to this proposed option, = but I do wonder if a DHCPv4 solution is merely a stopover on the road to = DHCPv6? Is there any benefit to somehow restricting its use to avoid a = large-scale migration from the Discover-Offer-Request-Ack cycle to the abbreviated exchange? Should we be developing what I see as an alternative to Mobile-IP? I'd like to see an updated client state transition diagram showing this exchange and updated message required field and option content tables covering the DHCPDISCOVER and DHCPACK message changes when you update = the draft. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 11:01:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15009; Thu, 6 Nov 2003 11:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmZG-00074K-M0; Thu, 06 Nov 2003 11:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmYy-00072a-Tj for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 11:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14830 for ; Thu, 6 Nov 2003 11:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYw-0002yj-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 11:00:46 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYR-0002um-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 11:00:45 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C362D454BA5; Thu, 6 Nov 2003 07:59:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19209-08; Thu, 6 Nov 2003 07:59:12 -0800 (PST) Received: from localhost.0.0.127.in-addr.arpa (hover.redback.com [155.53.42.186]) by prattle.redback.com (Postfix) with ESMTP id C712E454BA9; Thu, 6 Nov 2003 07:59:01 -0800 (PST) Subject: Re: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt From: Greg Kilfoyle To: Soohong Daniel Park Cc: dhcwg@ietf.org In-Reply-To: <011601c39764$a6e9cd90$b7cbdba8@daniel> References: <011601c39764$a6e9cd90$b7cbdba8@daniel> Content-Type: text/plain Message-Id: <1068133583.29601.452.camel@gar.kilfoyle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-2) Date: 06 Nov 2003 07:46:24 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Daniel, I'm afraid I'm not (yet) familiar with the IPv6 rapid reply mechanism and I'm only slowly coming up to speed on some of DHC drafts that are out there. Could you please clarify what sort of environment needs this mechanism? In well set up dhcp environments the entire 4-message dhcp exchange can be done in under 1 second, or at most a few seconds. Maybe the environments you are working with do not have this behavior. Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 12:04:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18521; Thu, 6 Nov 2003 12:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnY9-0003Y8-IZ; Thu, 06 Nov 2003 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnY2-0003Xr-5K for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 12:03:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18483 for ; Thu, 6 Nov 2003 12:03:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHnY0-0004Bm-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 12:03:52 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AHnXy-0004BN-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 12:03:51 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AHnXQ-0002vn-00; Thu, 06 Nov 2003 09:03:16 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5XAG5>; Thu, 6 Nov 2003 09:03:09 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Thu, 6 Nov 2003 09:03:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A487.DAC43DA0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A487.DAC43DA0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de] > Sent: Thursday, November 06, 2003 5:41 AM > To: Kostur, Andre; dhcwg@ietf.org > Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions > > > > > > To use DHCPFORCERENEW (DHCPRECONFIGURE), the client > must already > > > have a lease assigned! > > True, the device must already have a DHCP state machine > running. But if > > there's no state machine running, then the device is > choosing to not use > > DHCP! > [MR>] > The device should be configurable in terms of DHCP on > or off (as are > all devices I am aware of). > If the Discovery Extensions are supported, the acceptance of > DHCPCONFIGURE should be configurable. Additionally initial sending of > DHCPDISCOVER should be configurable. Are you therefore saying that devices will have DHCPCONFIGURE disabled by default? As well as sending an initial DHCPDISCOVER? (So by default the client does _nothing_ on bootup?) > > > With the Discovery Extensions I try to overcome this. > > > It's in fact a different philosophy to > "traditional" DHCP, even a > > > different protocol, that just uses the DHCP packet format > and the DHCP > > > infrastructure!! This point must be clearly understood. > > So you're trying to say that this draft only pertains to > unconfigured > > devices? And that DHCP servers should be extended to hold > information > > about devices that aren't performing DHCP (If it is > performing DHCP, then > > the server will learn about the device when it Discovers....)? > [MR>] > Yes. The server will learn about devices through > discovery: "Hey, > there is a device". > If the device is registered within the servers configuration > everything is fine. If it is not, the admin can be informed > ("Hey Admin, > there is a unregistered device") or any other appropriate > action taken. So you're agreeing that if the device is performing standard DHCP anyway, we already have the "discovery" feature? > > (Are we then duplicating effort with other > protocols/applications which > > deal with the network discovery stuff such as SNMP workstations?) > [MR>] > Yes and No. The Discovery Extensions allow both > configuration AND > supervision of the network. > It's up to the server, what it wants to use > > > > > > Right now there are some proprietary Discovery > Protocols under > > > development by some industry consortiums that go into > that direction. > > > But I don't want yet another proprietary packet format and > > protocol > > > infrastructure if I can easily adopt DHCP, which does > familiar things > > > anyway. Thats the background of my draft. > > OK, but DHCP isn't a device discovery protocol (and IMHO, > shouldn't be. > [MR>] > I think differently here... > Everybody how wants to use DHCP as ist is right now is > free to use > it that way in the future and can disable the Discovery > Extensions. They > won't get any disadvantage to what they have now. Yes, they do. They have the disadvantage of having to implement a more complex state machine on the client side, as well as additional logic on the server side. > Others who want to use it get a lot of functionality > through it. So far I haven't seen a whole lot of additional functionality that isn't already covered by other drafts and RFCs on the topic. > The Discover Extensions would be easy to implement. Right now they are unimplementable in a standard way since the behaviour is underspecified. > No additional states in the client's state machine required. Not true. There are a bunch more state transitions, and at least one more state where the device has received a DHCPCONFIGURE causing it to transition into a new State where the device emits a DHCPRELEASE and transitions into another state where it emits a DHCPREPORT, where then it finally transitions back into the Bound state. Plus whatever state transitions and states would be needed to express what the client is to do when it receives a NETSCAN in each state. Another thought... what happens if the device sends the RELEASE, then sends the REPORT, but the REPORT is lost? (keep in mind that this is all UDP... UDP packets may get dropped). > I can see only advantages...:-) > > Designing a completely new protocol for device discovery would > create a lot of overhead in the client (memory in small > clients !!), and it > would have to interact with DHCP anyway on the configuration > level on both > the client and the server... It would only have to interact with DHCP in a rudimentary way. All this other protocol would need to do is cause the existing DHCP client to either transition from the Bound to Renewing state, or possibly transition from any state to the Init-Reboot state. Leave the rest of the configuration up to Standard DHCP. > > And devices which are configured to be using DHCP will, at > some point, > > broadcast Discover, at which point the device will be > "discovered"). And > > there is at least one other "Discovery Protocol" mechanism > that would work > > almost as well (using existing protocols)... performing > ICMP Echos to > > determine if there is a device, followed by performing an > SNMP Walk on the > > target device. > [MR>] > This allows only discovery of devices that already have their IP > addresses assigned and are reachable on the IP layer! If a device is > misconfigured and not reachable through IP, there is no SNMP walk... > > The Discovery Extensions would allow communication > between server > and client on the Layer 2, prior to IP address allocation! > Conmmunicate with > clients that are not reachable through IP is always possible!! > > > > > - The DHCP Client behaviour talks about an "initially granting > > server", > > > > what if the device has not yet been granted a lease > from any server? > > > [MR>] See my point above. In that case it is > configuration, not > > reconfiguration! > > > Reconfiguration should be restricted to the > initially granting > > server, but not configuration. > > > > But then the draft is confusing. The draft talks about an initially > > granting server (thus the device already has a lease), and > you're talking > > about configuration (thus the device has no initially > granting server).... > > > [MR>] > Both should be possible: configuration AND > reconfiguration, as the > server pleases... We already have a mechanism for reconfiguration. Why reinvent the wheel, which only adds additional overhead? > > Sure it's configurable. But your draft sets it up in the > default case > > that "A broadcasted DHCPNETSCAN message SHOULD be > broadcasted into a relay > > agent's other subnets." (Actually, I just noticed that by > default the > > draft wants all REPORTs to be broadcast too... so that one > DHCPNETSCAN > > which is sent across your network results in potentially > everybody on your > > network broadcasting back to you.... now there's an > efficient DDoS attack > > on your entire DHCP infrastructure!) > [MR>] > That's correct. That's why it should only be > configurable and only > be used in closed networks that the administrator wants to > tigthly control. However your draft specifies that the default behaviour is to cause broadcast storms across your entire network (and it even goes so far as to suggest doing it periodically). So, there's two possiblities here. One is that DHCPCONFIGURE is enabled on clients by default, thus only one mildly malicious user can emit a NETSCAN once an hour and cause your entire network of 200000 devices to DDoS your real DHCP server by hammering it with 200000 REPORTs, or DHCPCONFIGURE is diabled on clients by default, and you need to go and manually enable every client to support it (in which case why not simply enable standard DHCP, and you get your discovery and reconfiguration features anyway (assuming 3203 is implemented) )? > The default value is on the server this case !! > Again: The operator of the server has the full responsibility of > what he is doing! Everything depends on the server > implementation, that > gives the protocol its flexibility. Famous last words. Administrators will configure as little as possible to get the service running. They may not even see the "feature" of this NETSCAN, so it will be left at its default values. This server is then deployed onto a broadband network with 200000 subscribers...... need I say more? > > > [MR>] "The client MUST omit any parameters it cannot > > > provide." (see chapter 5). This should of course also be > mentioned in > > chapter 3.3. > > You may wish to reword that to something along the lines of > "these options > > are required to be sent by the client, all other options > MAY (MUST?) be > > included if the client has pertinent information". > [MR>] Good suggestion. > > ...... > > > [MR>] First RELEASE then REPORT. > > OK, what happens in the case: > > 1) Device A sends the RELEASE > > 2) Device B Discovers & Requests (since the IP is now > available, it was > > just released!) the now released IP > > 3) Device A REPORTs on that IP > > ? > [MR>] > The REPORT must of course use the new IP assigned with > DHCPCONFIGURE, since it is the REPORT's main job to tell the > rest of the > network that a certain client has a certain configuration. > So there should > be no problem. There's a big problem. There is now two devices with the same IP address. > > > > DHCP server redundancy is already covered in the > Failover draft. > > > [MR>] This is true. But server redundancy is not the > > > main purpose of the discovery extension. It's a nice > "side-effect" > > Not to sound nasty, but if this isn't a purpose of the discovery > > extension, why is it stated as a goal of the draft? > [MR>] > I published the draft to show the possible potential of the > discovery extensions and to get some feedback on which of > this possibilites > might be useful and which not. > A server implmentation may use the redundancy > possibility or not. > It's up to the server. But I wouldn't restrict the protocol > in a way that > usage of this possibility is not allowed. > The philosophy of the Discovery Extensions are: "The > client provides > means that the server can use if he wishes." The client only reacts to > actions from the server. Which is a fundamental change in the DHCP protocol. Currently it's the service that only reacts to actions from the clients (notwithstanding 3203). > > Another general comment about the draft. Offhand I think the > > DHCPCONFIGURE message is superfluous when there exists RFC > 3203. I don't > > see anything that that DHCPCONFIGURE does that > DHCPRECONFIGURE can't do. > > In the case of an "unconfigured" client, there's nothing > that needs to be > > done except wait for the device to naturally Discover. For > an already > > configured device we can send a FORCERENEW, and the device will > > immediately transition to the Renewing state, causing it to > perform a > > REQUEST/ACK sequence, at which point the device can > reconfigure itself > > based upon the data in the new ACK packet. > [MR>] > That's true. But there are the following limitations to the > mechanism in RFC 3203: > > --The client cannot get it's (new) configuration information to > other servers for redundancy (as it is possible with a broadcasted > DHCPREPORT). Not the client's reponsibility. That is covered by the Failover draft. > -- In the supervising case (the server sends a > DHCPNETSCAN to see if > all its sheep are still in their right places in the > network), using the > FROCERENEW mechanism would mean a four message exchange for > every client!! Three message exchange, BTW: FORCERENEW->REQUEST->ACK > I don't like this very much since it produces a lot of > unneccessary traffic. > > -- And again, there is no way to get informations about > unconfigured > silent devices. If it's unconfigured, that's because it has failed a DHCP transaction (thus the server has already heard from the device). If it's silent, then it's not doing DHCP at all anyway, so the NETSCAN will fall on deaf ears, and you still won't get the REPORT. > If FORCERENEW would also be able to set a "silent" device to the > INIT state, I would be happy with it > and DHCPCONFIGURE would indeed be superfluous (though I still > dislike the four message exchange, which is unneccessary when > the server > starts communication). But unfortunately it doesn't. See above (3 message exchange, and a silent device isn't doing DHCP at all) > The Discovery Extensions are a different approach, > please keep this > in mind. One shouldn't compare them too much to > client-originated DHCP since > they follow different philosophies. Then it is a different protocol, and should be treated as such. ------_=_NextPart_001_01C3A487.DAC43DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: DHCP Discovery Extensions

> -----Original Message-----
> From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.= de]
> Sent: Thursday, November 06, 2003 5:41 = AM
> To: Kostur, Andre; dhcwg@ietf.org
> Subject: AW: [dhcwg] ID's: DHCP Discovery = Extensions
>
>
>
> > >       = To use DHCPFORCERENEW (DHCPRECONFIGURE), the client
> must already
> > > have a lease assigned!
> > True, the device must already have a DHCP = state machine
> running.  But if
> > there's no state machine running, then the = device is
> choosing to not use
> > DHCP!
>       [MR>]
>       The device = should be configurable in terms of DHCP on
> or off (as are
> all devices I am aware of).
>       If the  = Discovery Extensions are supported, the acceptance of
> DHCPCONFIGURE should be configurable. = Additionally initial sending of
> DHCPDISCOVER should be configurable.

Are you therefore saying that devices will have = DHCPCONFIGURE disabled by default?  As well as sending an initial = DHCPDISCOVER?  (So by default the client does _nothing_ on = bootup?)

> > >       = With the Discovery Extensions I try to overcome this.
> > >       = It's in fact a different philosophy to
> "traditional" DHCP, even a
> > > different protocol, that just uses = the DHCP packet format
> and the DHCP
> > > infrastructure!! This point must be = clearly understood.
> > So you're trying to say that this draft = only pertains to
> unconfigured
> > devices?  And that DHCP servers = should be extended to hold
> information
> > about devices that aren't performing DHCP = (If it is
> performing DHCP, then
> > the server will learn about the device = when it Discovers....)? 
>       [MR>]  =
>       Yes. The server = will learn about devices through
> discovery: "Hey,
> there is a device".
>       If the device is = registered within the servers configuration
> everything is fine. If it is not, the admin can = be informed
> ("Hey Admin,
> there is a unregistered device") or any = other appropriate
> action taken.

So you're agreeing that if the device is performing = standard DHCP anyway, we already have the "discovery" = feature?

> > (Are we then duplicating effort with other =
> protocols/applications which
> > deal with the network discovery stuff such = as SNMP workstations?)
>       [MR>]
>       Yes and No. The = Discovery Extensions allow both
> configuration AND
> supervision of the network.
>       It's up to the = server, what it wants to use
>
> >  
> > >       = Right now there are some proprietary Discovery
> Protocols under
> > > development by some industry = consortiums that go into
> that direction.
> > >       = But I don't want yet another proprietary packet format and
> > protocol
> > > infrastructure if I can easily adopt = DHCP, which does
> familiar things
> > > anyway. Thats the background of my = draft.
> > OK, but DHCP isn't a device discovery = protocol (and IMHO,
> shouldn't be.
>       [MR>]
>       I think = differently here...
>       Everybody how = wants to use DHCP as ist is right now is
> free to use
> it that way in the future and can disable the = Discovery
> Extensions. They
> won't get any disadvantage to what they have = now.

Yes, they do.  They have the disadvantage of = having to implement a more complex state machine on the client side, as = well as additional logic on the server side.

>       Others who want = to use it get a lot of functionality
> through it.

So far I haven't seen a whole lot of additional = functionality that isn't already covered by other drafts and RFCs on = the topic.

>       The Discover = Extensions would be easy to implement.

Right now they are unimplementable in a standard way = since the behaviour is underspecified.

>       No additional = states in the client's state machine required.

Not true.  There are a bunch more state = transitions, and at least one more state where the device has received = a DHCPCONFIGURE causing it to transition into a new State where the = device emits a DHCPRELEASE and transitions into another state where it = emits a DHCPREPORT, where then it finally transitions back into the = Bound state.  Plus whatever state transitions and states would be = needed to express what the client is to do when it receives a NETSCAN = in each state.

Another thought... what happens if the device sends = the RELEASE, then sends the REPORT, but the REPORT is lost?  (keep = in mind that this is all UDP... UDP packets may get = dropped).

>       I can see only = advantages...:-)
>
>       Designing a = completely new protocol for device discovery would
> create a lot of overhead in the client (memory = in small
> clients !!), and it
> would have to interact with DHCP anyway on the = configuration
> level on both
> the client and the server...

It would only have to interact with DHCP in a = rudimentary way.  All this other protocol would need to do is = cause the existing DHCP client to either transition from the Bound to = Renewing state, or possibly transition from any state to the = Init-Reboot state.  Leave the rest of the configuration up to = Standard DHCP.

> > And devices which are configured to be = using DHCP will, at
> some point,
> > broadcast Discover, at which point the = device will be
> "discovered").  And
> > there is at least one other = "Discovery Protocol" mechanism
> that would work
> > almost as well (using existing = protocols)... performing
> ICMP Echos to
> > determine if there is a device, followed = by performing an
> SNMP Walk on the
> > target device. 
>       [MR>]
>       This allows only = discovery of devices that already have their IP
> addresses assigned and are reachable on the IP = layer! If a device is
> misconfigured and not reachable through IP, = there is no SNMP walk...
>
>       The Discovery = Extensions would allow communication
> between server
> and client on the Layer 2, prior to IP address = allocation!
> Conmmunicate with
> clients that are not reachable through IP is = always possible!!
>
> > > > - The DHCP Client behaviour = talks about an "initially granting
> > server",
> > > > what if the device has not yet = been granted a lease
> from any server?
> > >       = [MR>]  See my point above. In that case it is
> configuration, not
> > reconfiguration!
> > >       = Reconfiguration should be restricted to the
> initially granting
> > server, but not configuration.
> >
> > But then the draft is confusing.  The = draft talks about an initially
> > granting server (thus the device already = has a lease), and
> you're talking
> > about configuration (thus the device has = no initially
> granting server)....
> >
>       [MR>]
>       Both should be = possible: configuration AND
> reconfiguration, as the
> server pleases...

We already have a mechanism for reconfiguration. = Why reinvent the wheel, which only adds additional overhead?

> > Sure it's configurable.  But your = draft sets it up in the
> default case
> > that "A broadcasted DHCPNETSCAN = message SHOULD be
> broadcasted into a relay
> > agent's other subnets."  = (Actually, I just noticed that by
> default the
> > draft wants all REPORTs to be broadcast = too... so that one
> DHCPNETSCAN
> > which is sent across your network results = in potentially
> everybody on your
> > network broadcasting back to you.... now = there's an
> efficient DDoS attack
> > on your entire DHCP = infrastructure!)
>       [MR>]  =
>       That's correct. = That's why it should only be
> configurable and only
> be used in closed networks that the = administrator wants to
> tigthly control.

However your draft specifies that the default = behaviour is to cause broadcast storms across your entire network (and = it even goes so far as to suggest doing it periodically).  So, = there's two possiblities here.  One is that DHCPCONFIGURE is = enabled on clients by default, thus only one mildly malicious user can = emit a NETSCAN once an hour and cause your entire network of 200000 = devices to DDoS your real DHCP server by hammering it with 200000 = REPORTs, or DHCPCONFIGURE is diabled on clients by default, and you = need to go and manually enable every client to support it (in which = case why not simply enable standard DHCP, and you get your discovery = and reconfiguration features anyway (assuming 3203 is implemented) = )?

>       The default value = is on the server this case !!
>       Again: The = operator of the server has the full responsibility of
> what he is doing! Everything depends on the = server
> implementation, that
> gives the protocol its flexibility.

Famous last words.  Administrators will = configure as little as possible to get the service running.  They = may not even see the "feature" of this NETSCAN, so it will be = left at its default values.  This server is then deployed onto a = broadband network with 200000 subscribers...... need I say = more?

 
> > >       = [MR>]  "The client MUST omit any parameters it cannot =
> > > provide." (see chapter 5). This = should of course also be
> mentioned in
> > chapter 3.3.
> > You may wish to reword that to something = along the lines of
> "these options
> > are required to be sent by the client, all = other options
> MAY (MUST?) be
> > included if the client has pertinent = information".
>       [MR>]  = Good suggestion.
>
>       ......
> > >       = [MR>]  First RELEASE then REPORT.
> > OK, what happens in the case:
> > 1) Device A sends the RELEASE
> > 2) Device B Discovers & Requests = (since the IP is now
> available, it was
> > just released!) the now released IP =
> > 3) Device A REPORTs on that IP
> > ?
>       [MR>]  =
>       The REPORT must = of course use the new IP assigned with
> DHCPCONFIGURE, since it is the REPORT's main = job to tell the
> rest of the
> network that a certain client has a certain = configuration. 
> So there should
> be no problem.

There's a big problem.  There is now two devices = with the same IP address.

> > > > DHCP server redundancy is already = covered in the
> Failover draft.
> > >       = [MR>]  This is true. But server redundancy is not the
> > > main purpose of the discovery = extension. It's a nice
> "side-effect" 
> > Not to sound nasty, but if this isn't a = purpose of the discovery
> > extension, why is it stated as a goal of = the draft?
>       [MR>]
>       I published the = draft to show the possible potential of the
> discovery extensions and to get some feedback = on which of
> this possibilites
> might be useful and which not.
>       A server = implmentation may use the redundancy
> possibility or not.
> It's up to the server. But I wouldn't restrict = the protocol
> in a way that
> usage of this possibility is not allowed. =
>       The philosophy = of the Discovery Extensions are: "The
> client provides
> means that the server can use if he = wishes." The client only reacts to
> actions from the server.

Which is a fundamental change in the DHCP = protocol.  Currently it's the service that only reacts to actions = from the clients (notwithstanding 3203).

 
> > Another general comment about the = draft.  Offhand I think the
> > DHCPCONFIGURE message is superfluous when = there exists RFC
> 3203.  I don't
> > see anything that that DHCPCONFIGURE does = that
> DHCPRECONFIGURE can't do.
> > In the case of an "unconfigured" = client, there's nothing
> that needs to be
> > done except wait for the device to = naturally Discover.  For
> an already
> > configured device we can send a = FORCERENEW, and the device will
> > immediately transition to the Renewing = state, causing it to
> perform a
> > REQUEST/ACK sequence, at which point the = device can
> reconfigure itself
> > based upon the data in the new ACK = packet.
>       [MR>]  =
>       That's true. But = there are the following limitations to the
> mechanism in RFC 3203:
>
>       --The client = cannot get it's (new) configuration information to
> other servers for redundancy (as it is possible = with a broadcasted
> DHCPREPORT).

Not the client's reponsibility.  That is covered = by the Failover draft.
 
>       -- In the = supervising case (the server sends a
> DHCPNETSCAN to see if
> all its sheep are still in their right places = in the
> network), using the
> FROCERENEW mechanism would mean a four message = exchange for
> every client!!

Three message exchange, BTW: = FORCERENEW->REQUEST->ACK

> I don't like this very much since it produces a = lot of
> unneccessary traffic.
>
>       -- And again, = there is no way to get informations about
> unconfigured
> silent devices.

If it's unconfigured, that's because it has failed a = DHCP transaction (thus the server has already heard from the = device).  If it's silent, then it's not doing DHCP at all anyway, = so the NETSCAN will fall on deaf ears, and you still won't get the = REPORT.

>       If FORCERENEW = would also be able to set a "silent" device to the
> INIT state, I would be happy with it
>       and = DHCPCONFIGURE would indeed be superfluous (though I still
> dislike the four message exchange, which is = unneccessary when
> the server
> starts communication). But unfortunately it = doesn't.

See above (3 message exchange, and a silent device = isn't doing DHCP at all)

>       The Discovery = Extensions are a different approach,
> please keep this
> in mind. One shouldn't compare them too much to =
> client-originated DHCP since
> they follow different philosophies.

Then it is a different protocol, and should be = treated as such.

------_=_NextPart_001_01C3A487.DAC43DA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 12:59:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20477; Thu, 6 Nov 2003 12:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoPN-0006vZ-9L; Thu, 06 Nov 2003 12:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoP9-0006vF-D8 for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 12:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20463 for ; Thu, 6 Nov 2003 12:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoP7-0004xJ-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 12:58:45 -0500 Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by ietf-mx with smtp (Exim 4.12) id 1AHoP7-0004xD-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 12:58:45 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 17:58:42 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Thu, 6 Nov 2003 09:58:12 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <000001c3a471$d7c0eab0$6401a8c0@BVolz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie-- I can definitely see how this proposal could be of value in certain circumstances, so thanks for considering my questions! --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 13:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21725; Thu, 6 Nov 2003 13:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHosP-0008Ix-GO; Thu, 06 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHos5-0008IQ-QH for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 13:28:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21693 for ; Thu, 6 Nov 2003 13:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHos3-0005Qu-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 13:28:39 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AHos3-0005Ql-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 13:28:39 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AHorS-0004Du-00; Thu, 06 Nov 2003 10:28:02 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5XAQF>; Thu, 6 Nov 2003 10:27:52 -0800 Message-ID: From: "Kostur, Andre" To: "'Bernie Volz'" , rbhibbs@pacbell.net, dhcwg@ietf.org Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Thu, 6 Nov 2003 10:27:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A493.AFF2F970" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A493.AFF2F970 Content-Type: text/plain; charset="iso-8859-1" Offhand I'm thinking that a Rapid Commit option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously. However I would suggest that the draft specify that by default DHCP Servers SHOULD have Rapid Reply disabled. Oh, and a minor comment: I think the option should be renamed to be "Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the inspiration of this option). > -----Original Message----- > From: Bernie Volz [mailto:volz@metrocast.net] > Sent: Thursday, November 06, 2003 6:26 AM > To: rbhibbs@pacbell.net; dhcwg@ietf.org > Subject: RE: [dhcwg] FW: I-D > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > Barr: > > These are good questions and should be addressed. I don't > have any specific > case where the Rapid Reply is really desired. As far as > restrictions, I > would expect any migration would be slow (because of the > large deployed > client base) and servers should be configurable as to whether > they allow it > to be used - such as in cases where multiple servers exist > (though coupled > with failover, this option could be very useful to expedite > configuration). > Regarding an updated state diagram and processing > description, we should > provide that (though there are others that have indicated > they'd rather not > have state diagrams). > > Daniel will present this work at the DHC WG meeting next week > and we'll > revise the draft with that input and any Mailing List input > (such as yours). > This assumes that the general consensus is work should > continue on this. > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Barr > Hibbs > Sent: Thursday, November 06, 2003 12:35 AM > To: dhcwg@ietf.org > Subject: RE: [dhcwg] FW: I-D > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > Daniel, Bernie-- > > is there sufficient demand for a DHCPv4 solution to highly > mobile devices > that this option is necessary? I don't object to this > proposed option, but > I do wonder if a DHCPv4 solution is merely a stopover on the > road to DHCPv6? > > Is there any benefit to somehow restricting its use to avoid > a large-scale > migration from the Discover-Offer-Request-Ack cycle to the abbreviated > exchange? Should we be developing what I see as an alternative to > Mobile-IP? > > I'd like to see an updated client state transition diagram > showing this > exchange and updated message required field and option content tables > covering the DHCPDISCOVER and DHCPACK message changes when > you update the > draft. > > --Barr > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C3A493.AFF2F970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] FW: I-D = ACTION:draft-volz-dhc-rapidreply-opt-00.txt

Offhand I'm thinking that a Rapid Commit option would = be handy, particularly in environments that may have a large number of = devices attempting to Discover simultaneously.  However I would = suggest that the draft specify that by default DHCP Servers SHOULD have = Rapid Reply disabled.

Oh, and a minor comment: I think the option should be = renamed to be "Rapid Commit" instead of Rapid Reply to be = consistent with DHCPv6 (which is the inspiration of this = option).

 
> -----Original Message-----
> From: Bernie Volz [mailto:volz@metrocast.net]=
> Sent: Thursday, November 06, 2003 6:26 = AM
> To: rbhibbs@pacbell.net; dhcwg@ietf.org
> Subject: RE: [dhcwg] FW: I-D
> = ACTION:draft-volz-dhc-rapidreply-opt-00.txt
>
>
> Barr:
>
> These are good questions and should be = addressed. I don't
> have any specific
> case where the Rapid Reply is really desired. = As far as
> restrictions, I
> would expect any migration would be slow = (because of the
> large deployed
> client base) and servers should be configurable = as to whether
> they allow it
> to be used - such as in cases where multiple = servers exist
> (though coupled
> with failover, this option could be very useful = to expedite
> configuration).
> Regarding an updated state diagram and = processing
> description, we should
> provide that (though there are others that have = indicated
> they'd rather not
> have state diagrams).
>
> Daniel will present this work at the DHC WG = meeting next week
> and we'll
> revise the draft with that input and any = Mailing List input
> (such as yours).
> This assumes that the general consensus is work = should
> continue on this.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] = On
> Behalf Of Barr
> Hibbs
> Sent: Thursday, November 06, 2003 12:35 = AM
> To: dhcwg@ietf.org
> Subject: RE: [dhcwg] FW: I-D
> = ACTION:draft-volz-dhc-rapidreply-opt-00.txt
>
>
> Daniel, Bernie--
>
> is there sufficient demand for a DHCPv4 = solution to highly
> mobile devices
> that this option is necessary?  I don't = object to this
> proposed option, but
> I do wonder if a DHCPv4 solution is merely a = stopover on the
> road to DHCPv6?
>
> Is there any benefit to somehow restricting its = use to avoid
> a large-scale
> migration from the Discover-Offer-Request-Ack = cycle to the abbreviated
> exchange?  Should we be developing what I = see as an alternative to
> Mobile-IP?
>
> I'd like to see an updated client state = transition diagram
> showing this
> exchange and updated message required field and = option content tables
> covering the DHCPDISCOVER and DHCPACK message = changes when
> you update the
> draft.
>
> --Barr
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>
>
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C3A493.AFF2F970-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 13:51:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22710; Thu, 6 Nov 2003 13:51:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpDg-0001A8-PR; Thu, 06 Nov 2003 13:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpDb-00019q-EP for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 13:50:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22698 for ; Thu, 6 Nov 2003 13:50:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpDZ-0005np-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 13:50:53 -0500 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 1AHpDY-0005nm-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 13:50:52 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 18:50:51 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Thu, 6 Nov 2003 10:50:22 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <004201c3a42f$e2e59220$38e62a0f@nt23056> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit clarifications.... --Barr > > > > Second, although options 66 and 67 were intended to simply > > provide a way to represent the contents of the BOOTP 'sname' > > and 'file' fields in options, I question the appropriateness > > of using a name rather than IP address for the > > server: in other words, I'd like to see option 66 changed to > > use IP address rather than name to identify the server, and > > I'd also like to see the same convention used in this draft. > > I agree with you that dns name is not very appropriate here.. Since, RFC > 2131 defines sname as name and the representation of tftp server as name > is deployed and widely used in many bootp servers without any > complaints, I really didn't want to change the widely used model... But, > the provision to represent tftp server as IP address can be added.. > ...see the other message exchange with Bernie: his point was that by its very nature, using a DNS name for the 'sname' field ensures a degree of redundancy, in that the resolver permits a degree of abstraction. If a list of IP addresses is supplied, I contend that is equivalent to the DNS name redundancy. Certainly a topic for further discussion. > A new suboption (op code: 1) can be defined for Remote Boot Information > suboption to carry a tftp server address. Either this option or option > 66 can appear in the ts field... > ....interesting point -- I'd assumed that when you said "option 66" you meant "a DNS name, just as [current] option 66 uses." What I'd like is for ALL DHCP options that contain addresses to carry them as IP addresses for consistency across the entire option space. Looks like another discussion item for the RFC 2131 review! > > > > I'm not sure that I agree that file name(s) should be coupled > > to a specific server name: shouldn't the boot file name(s) > > be identical for all servers that offer the remote bootstrap > > service? > > The one reason I could think of is, as bernie told, the path may be > different in different servers.. I believe, there is nothing wrong in > keeping in providing this flexibility... In the case, where the file > names are same, the provision can be made in this option to specify only > the tftp server/name and take the file names from its previous Remote > Boot Information suboption, which has the file names.. In this way, we > can keep both the flexibility and the save space in the bootp message.. > ...yes, Bernie's point was well-taken: I've changed my view slightly and think that we ought to be able to supply: o a [set of] file name[s] specific to each server identified as offering TFTP remote boot services appropriate for the client, -- OR -- o a single [set of] file name[s] that is correct for all servers identified as offering TFTP remote boot services appropriate for the client. This might take the form of a simple marker [suboption code] that carries the meaning "file name(s) for this server are identical to the list supplied with the first server address supplied. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 14:16:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23761; Thu, 6 Nov 2003 14:16:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpbu-00034E-2Y; Thu, 06 Nov 2003 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpbr-00032n-Lq for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 14:15:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23733 for ; Thu, 6 Nov 2003 14:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpbp-0006A7-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 14:15:57 -0500 Received: from smtp014.mail.yahoo.com ([216.136.173.58]) by ietf-mx with smtp (Exim 4.12) id 1AHpbo-0006A4-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 14:15:56 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 19:15:55 -0000 Reply-To: From: "Barr Hibbs" To: "Rentschler, Markus" , Subject: RE: [dhcwg] ID's: Interface Information Option Date: Thu, 6 Nov 2003 11:15:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit comments inline.... --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Rentschler, Markus > Sent: Thursday, November 06, 2003 00:11 > > > > What benefit does this particular option give over simply using the > > existing Client Identifier (Opt 61) to encode such information? > > [MR>] There are several benefits: > > > > -- Another parameter for more tightly IP address allocation schemes for > > higher security. (The server configurator can for example say: a certain > > IP address/configuration is only allowed to a certain client > > (use MAC and /or Client-Id) on a certain location in the network topology > > (use Option 82) that is connected via a certain interface (use IIO). > > Any other useful combinations with other client's parameter as trigger > > conditions may be thought of... > > -- Possibility for topology discovery and therefore detection of > > misconfigured connections. > > ...you've obviously never had to manage an extremely large, widely dispersed client population with a diverse technician workforce. It is AN EXTREMELY BAD IDEA to try to "lock-down" devices by insisting on strict, unchanging relationships between MAC addresses, Client Identifiers, Host Names, hub, switch, or router ports, and other network elements. The principal benefit of DHCP is to reduce the need for detailed recordkeeping and configuration which represents a huge savings in labor costs, and reduced troubleshooting and repair times. Don't arbitrarily throw out that major benefit in the pursuit of the elusive goal of "improved security" -- when was the last time your organization, or ANY organization of which you had knowledge, was penetrated by someone plugging in an unauthorized network device? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 14:52:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25720; Thu, 6 Nov 2003 14:52:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqAi-0006GJ-BC; Thu, 06 Nov 2003 14:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHq9q-0006FF-LH for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 14:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25661 for ; Thu, 6 Nov 2003 14:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHq9n-0006ol-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 14:51:03 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AHq9n-0006oi-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 14:51:03 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 354301B2193; Thu, 6 Nov 2003 13:44:43 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C010AAB-1092-11D8-818A-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] IDs on remote boot support for DHCP Date: Thu, 6 Nov 2003 13:51:00 -0600 To: X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 6, 2003, at 12:50 PM, Barr Hibbs wrote: > ...see the other message exchange with Bernie: his point was that by > its > very nature, using a DNS name for the 'sname' field ensures a degree of > redundancy, in that the resolver permits a degree of abstraction. If > a list > of IP addresses is supplied, I contend that is equivalent to the DNS > name > redundancy. Certainly a topic for further discussion. I've never heard of anybody using the sname field for anything. I'd like to see its use deprecated, along with the server-name option. I think we should have a single way of getting the identity of the server to contact, not fifteen different ways (okay, I'm exaggerating, but you get the idea). Otherwise, neither the administrator nor the client implementor has any real way of anticipating which method to implement, or which to prefer if multiple methods are offered and multiple methods are implemented. So you wind up with the sysadmin playing a big guessing game. Yuck. Frankly, I'm skeptical about any proposal to add a new method in DHCPv4 for determining what file to load, or where to load it - we should have a good reason for doing this, not just "this way is better." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 16:49:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02897; Thu, 6 Nov 2003 16:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrzy-0006Qb-5z; Thu, 06 Nov 2003 16:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrzh-0006Pf-JQ for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 16:48:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02840 for ; Thu, 6 Nov 2003 16:48:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrzf-00019r-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 16:48:43 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1AHrzb-00019o-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 16:48:39 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 48A2E1C00FEA; Thu, 6 Nov 2003 13:48:37 -0800 (PST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id DAA29055; Fri, 7 Nov 2003 03:17:22 +0530 (IST) Message-ID: <3FAAC1B2.3080109@india.hp.com> Date: Fri, 07 Nov 2003 03:18:34 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: Re: [dhcwg] IDs on remote boot support for DHCP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Barr Hibbs wrote: >clarifications.... > >--Barr > > > > >>>Second, although options 66 and 67 were intended to simply >>>provide a way to represent the contents of the BOOTP 'sname' >>>and 'file' fields in options, I question the appropriateness >>>of using a name rather than IP address for the >>>server: in other words, I'd like to see option 66 changed to >>>use IP address rather than name to identify the server, and >>>I'd also like to see the same convention used in this draft. >>> >>> >>I agree with you that dns name is not very appropriate here.. Since, RFC >>2131 defines sname as name and the representation of tftp server as name >>is deployed and widely used in many bootp servers without any >>complaints, I really didn't want to change the widely used model... But, >>the provision to represent tftp server as IP address can be added.. >> >> >> >...see the other message exchange with Bernie: his point was that by its >very nature, using a DNS name for the 'sname' field ensures a degree of >redundancy, in that the resolver permits a degree of abstraction. If a list >of IP addresses is supplied, I contend that is equivalent to the DNS name >redundancy. Certainly a topic for further discussion. > > > > >>A new suboption (op code: 1) can be defined for Remote Boot Information >>suboption to carry a tftp server address. Either this option or option >>66 can appear in the ts field... >> >> >> >....interesting point -- I'd assumed that when you said "option 66" you >meant "a DNS name, just as [current] option 66 uses." What I'd like is for >ALL DHCP options that contain addresses to carry them as IP addresses for >consistency across the entire option space. Looks like another discussion >item for the RFC 2131 review! > > > > >>>I'm not sure that I agree that file name(s) should be coupled >>>to a specific server name: shouldn't the boot file name(s) >>>be identical for all servers that offer the remote bootstrap >>>service? >>> >>> >>The one reason I could think of is, as bernie told, the path may be >>different in different servers.. I believe, there is nothing wrong in >>keeping in providing this flexibility... In the case, where the file >>names are same, the provision can be made in this option to specify only >>the tftp server/name and take the file names from its previous Remote >>Boot Information suboption, which has the file names.. In this way, we >>can keep both the flexibility and the save space in the bootp message.. >> >> >> >...yes, Bernie's point was well-taken: I've changed my view slightly and >think that we ought to be able to supply: > > o a [set of] file name[s] specific to each server identified as offering > TFTP remote boot services appropriate for the client, > > -- OR -- > > o a single [set of] file name[s] that is correct for all servers >identified > as offering TFTP remote boot services appropriate for the client. > >This might take the form of a simple marker [suboption code] that carries >the meaning "file name(s) for this server are identical to the list supplied >with the first server address supplied. > > > how about multiple set of servers with their distinct file names? In this case, the simple marker wont be useful.. the solution could be, the tftp server option w/o file name will be assumed to have the same file name of the preceding server with some file name.. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 17:20:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04749; Thu, 6 Nov 2003 17:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsU1-0000mg-DF; Thu, 06 Nov 2003 17:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsTq-0000kJ-F9 for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 17:19:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04691 for ; Thu, 6 Nov 2003 17:19:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsTo-0001r6-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 17:19:52 -0500 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 1AHsTn-0001qv-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 17:19:51 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 22:19:45 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Thu, 6 Nov 2003 14:19:16 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3FAAC1B2.3080109@india.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > how about multiple set of servers with their distinct file names? > In this case, the simple marker wont be useful.. the solution > could be, the tftp server option w/o file name will be assumed to > have the same file name of the preceding server with some file name.. > ...perhaps I didn't express myself clearly: I think that we should be able to accommodate either a file name list OR a simple marker that indicates "use the previous file name list" on a per-server basis --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 6 18:09:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07123; Thu, 6 Nov 2003 18:09:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtFN-0004Hv-Pi; Thu, 06 Nov 2003 18:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtEu-0004HR-6Z for dhcwg@optimus.ietf.org; Thu, 06 Nov 2003 18:08:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07004 for ; Thu, 6 Nov 2003 18:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtEr-0002Yk-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 18:08:29 -0500 Received: from smtp015.mail.yahoo.com ([216.136.173.59]) by ietf-mx with smtp (Exim 4.12) id 1AHtEq-0002Yb-00 for dhcwg@ietf.org; Thu, 06 Nov 2003 18:08:28 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Nov 2003 23:08:27 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Thu, 6 Nov 2003 15:07:58 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <8C010AAB-1092-11D8-818A-000A95D9C74C@fugue.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ted-- Rob and I have already suggested that the use of the 'sname' and 'file' fields be not just deprecated, but removed from the DHCP packet format (see our I-D on RFC 2131 implementation issues that was discussed this morning in the WG meeting) to expand the 'options' field and eliminate all of that muck about overloading the 'sname' and 'file' fields. The big question is "are there ANY DHCP clients that use 'sname' and 'file' or options 66 and 67 to locate part of their boot images, or are all users of this feature BOOTP clients? --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Thursday, November 06, 2003 11:51 > > I've never heard of anybody using the sname field for anything. I'd > like to see its use deprecated, along with the server-name option. I > think we should have a single way of getting the identity of the server > to contact, not fifteen different ways (okay, I'm exaggerating, but you > get the idea). Otherwise, neither the administrator nor the client > implementor has any real way of anticipating which method to implement, > or which to prefer if multiple methods are offered and multiple methods > are implemented. So you wind up with the sysadmin playing a big > guessing game. Yuck. Frankly, I'm skeptical about any proposal to > add a new method in DHCPv4 for determining what file to load, or where > to load it - we should have a good reason for doing this, not just > "this way is better." > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 03:11:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04703; Fri, 7 Nov 2003 03:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1hu-0005wH-KL; Fri, 07 Nov 2003 03:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1hN-0005vN-9C for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 03:10:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04636 for ; Fri, 7 Nov 2003 03:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1hI-0000rT-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 03:10:25 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AI1hI-0000qi-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 03:10:24 -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 <0HNZ00KW22OHPP@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:09:53 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNZ00K6J2LD3V@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:08:01 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNZ008V52LDNT@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:08:01 +0900 (KST) Date: Fri, 07 Nov 2003 17:08:23 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt In-reply-to: To: "'Kostur, Andre'" , "'Bernie Volz'" , rbhibbs@pacbell.net, dhcwg@ietf.org Cc: "'Soohong Daniel Park'" Message-id: <008a01c3a506$506aa8e0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_VnuHVp5bNadkS57ihchRIw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_VnuHVp5bNadkS57ihchRIw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hello Kostur Offhand I'm thinking that a Rapid Commit option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously. However I would suggest that the draft specify that by default DHCP Servers SHOULD have Rapid Reply disabled. => typo disabled / enabled correct ? Oh, and a minor comment: I think the option should be renamed to be "Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the inspiration of this option). => interesting. originally I tried to distinguish this option from option of dhcpv6. I will consider it. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics --Boundary_(ID_VnuHVp5bNadkS57ihchRIw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

Hello Kostur

Offhand I'm thinking that a Rapid Commit option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously.  However I would suggest that the draft specify that by default DHCP Servers SHOULD have Rapid Reply disabled.

=> typo disabled / enabled  correct ?

Oh, and a minor comment: I think the option should be renamed to be "Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the inspiration of this option).

=> interesting. originally I tried to distinguish this option from option of dhcpv6. I will consider it.

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

--Boundary_(ID_VnuHVp5bNadkS57ihchRIw)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 03:17:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04878; Fri, 7 Nov 2003 03:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1nh-0006Kx-8Y; Fri, 07 Nov 2003 03:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1nH-0006Hs-HV for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 03:16:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04838 for ; Fri, 7 Nov 2003 03:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1nE-0000wx-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 03:16:32 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AI1nD-0000wZ-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 03:16:31 -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 <0HNZ00L212YOCR@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:16:00 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNZ00KKI2YG36@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:15:53 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNZ009YB2YGVU@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 17:15:52 +0900 (KST) Date: Fri, 07 Nov 2003 17:16:14 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt In-reply-to: To: rbhibbs@pacbell.net, dhcwg@ietf.org Cc: "'Soohong Daniel Park'" , "'Bernie Volz'" Message-id: <009401c3a507$697168a0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Barr Thanks your good questions and inputs. Bernie and I will consider yours in the revised draft as well. >Should we be developing what I see as an alternative to >Mobile-IP? My understanding is that MIP is not used for a host at this stage. Generally we may make use of IP addresses from dhcp server in the wireless environment (wireless lan is described in this draft) Comments ? 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-admin@ietf.org Fri Nov 7 04:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06513; Fri, 7 Nov 2003 04:14:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2gq-0001Rg-TT; Fri, 07 Nov 2003 04:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2g7-0001QG-45 for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 04:13:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06494 for ; Fri, 7 Nov 2003 04:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2g4-0001b4-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:13:12 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AI2g3-0001ad-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:13:11 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hA79Cdp9089830 for ; Fri, 7 Nov 2003 10:12:40 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hA79CchE089808 for ; Fri, 7 Nov 2003 10:12:38 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hA79Cap7089805; Fri, 07 Nov 2003 10:12:38 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B4F4FDAE29; Fri, 7 Nov 2003 09:35:35 +0100 (CET) Date: Fri, 07 Nov 2003 10:12:30 +0100 From: Martin Stiemerling To: Ron Lee Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 server availability Message-ID: <2887942.1068199950@[10.1.1.109]> In-Reply-To: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> References: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, --On Donnerstag, 6. November 2003 17:01 +0900 Ron Lee wrote: | | Hello, I am wondering which companies have implemented DHCPv6 server. You probably have to ask the companies directly. | I know there are 6 major vendors who participated in the conformance | testing in the past July IETF meeting, but I cannot find the result. The interop was quite successful, but the results are under non-disclosure agreement. Martin | | Any related information is greatly appreciated. | Thanks. | | ========================================================== | Ron Lee | Senior Engineer | | Telecommunication Division, | Samsung Electronics Co., Ltd | Suwon, South Korea | | | _______________________________________________ | dhcwg mailing list | dhcwg@ietf.org | https://www1.ietf.org/mailman/listinfo/dhcwg Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 04:56:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08232; Fri, 7 Nov 2003 04:56:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3LV-0004cf-Vj; Fri, 07 Nov 2003 04:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Kl-0004cF-28 for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 04:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08203 for ; Fri, 7 Nov 2003 04:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Kh-0002GT-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:55:11 -0500 Received: from batch11.uni-muenster.de ([128.176.188.109]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Kh-0002GQ-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:55:11 -0500 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch11.uni-muenster.de (Postfix) with ESMTP id CE45D608D; Fri, 7 Nov 2003 10:54:27 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 4D4AB312F1; Fri, 7 Nov 2003 10:54:26 +0100 (CET) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 8E5E8312F5; Fri, 7 Nov 2003 10:54:25 +0100 (CET) Subject: Re: [dhcwg] DHCPv6 server availability From: Christian Strauf To: Martin Stiemerling Cc: Ron Lee , dhcwg@ietf.org In-Reply-To: <2887942.1068199950@[10.1.1.109]> References: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> <2887942.1068199950@[10.1.1.109]> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1068198909.4819.11.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 07 Nov 2003 10:55:10 +0100 X-Virus-Scanned: by AMaViS 0.3.12pre7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA08204 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Martin, > | Hello, I am wondering which companies have implemented DHCPv6 server. > You probably have to ask the companies directly. I've also been trying to find server implementations. Unfortunately I wasn't able to find the companies that participated in the plug-tests either. Can you point us to these companies? > The interop was quite successful, but the results are under non-disclos= ure=20 If it was successful, why would the companies want to keep them under NDA? Just wondering. Anyhow, is there a release of the interop results scheduled some time in the near future? Cheers, Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 10:23:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18343; Fri, 7 Nov 2003 10:23:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8Rx-0002on-Ac; Fri, 07 Nov 2003 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8R5-0002oF-Qr for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 10:22:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18272 for ; Fri, 7 Nov 2003 10:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8R3-0006Jw-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 10:22:05 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AI8R2-0006Jf-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 10:22:04 -0500 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HNZ00801LMOB0@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 10:21:28 -0500 (EST) Received: from kan1 (user127.net384.oh.sprint-hsd.net [65.40.69.127]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HNZ00FBSMNQB6@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 10:21:28 -0500 (EST) Date: Fri, 07 Nov 2003 10:21:27 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] IDs on remote boot support for DHCP In-reply-to: To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT To the best of my knowledge, DOCSIS still specifies the use of the 'file' field for booting cable modems. I've never seen 'sname' used. --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Barr Hibbs Sent: Thursday, 06 November, 2003 6:08 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] IDs on remote boot support for DHCP Ted-- Rob and I have already suggested that the use of the 'sname' and 'file' fields be not just deprecated, but removed from the DHCP packet format (see our I-D on RFC 2131 implementation issues that was discussed this morning in the WG meeting) to expand the 'options' field and eliminate all of that muck about overloading the 'sname' and 'file' fields. The big question is "are there ANY DHCP clients that use 'sname' and 'file' or options 66 and 67 to locate part of their boot images, or are all users of this feature BOOTP clients? --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Thursday, November 06, 2003 11:51 > > I've never heard of anybody using the sname field for anything. I'd > like to see its use deprecated, along with the server-name option. I > think we should have a single way of getting the identity of the server > to contact, not fifteen different ways (okay, I'm exaggerating, but you > get the idea). Otherwise, neither the administrator nor the client > implementor has any real way of anticipating which method to implement, > or which to prefer if multiple methods are offered and multiple methods > are implemented. So you wind up with the sysadmin playing a big > guessing game. Yuck. Frankly, I'm skeptical about any proposal to > add a new method in DHCPv4 for determining what file to load, or where > to load it - we should have a good reason for doing this, not just > "this way is better." > > > _______________________________________________ > 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-admin@ietf.org Fri Nov 7 10:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18892; Fri, 7 Nov 2003 10:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8eY-0003QH-B2; Fri, 07 Nov 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8e1-0003Po-Mc for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 10:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18839 for ; Fri, 7 Nov 2003 10:35:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8dz-0006Td-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 10:35:27 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AI8dy-0006TQ-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 10:35:26 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AI8dS-0002pT-00; Fri, 07 Nov 2003 07:34:54 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5XDSV>; Fri, 7 Nov 2003 07:34:48 -0800 Message-ID: From: "Kostur, Andre" To: "'Soohong Daniel Park'" , dhcwg@ietf.org Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Fri, 7 Nov 2003 07:34:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A544.ACB30B40" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A544.ACB30B40 Content-Type: text/plain; charset="iso-8859-1" No, I actually meant disabled. Recall that DHCP was designed to work in a scenario where there are multiple DHCP servers performing offers to clients. Rapid Commit/Reply is basically a feature where you tell the service that there isn't multiple DHCP servers (changing the default assumption in the protocol). So... by default all DHCP servers will work properly in a multi-server environment unless it is explicitly told that it is the only server that will be answering (where "only" may include load-balanced and/or failover enabled pairs). -----Original Message----- From: Soohong Daniel Park [mailto:soohong.park@samsung.com] Sent: Friday, November 07, 2003 12:08 AM To: 'Kostur, Andre'; 'Bernie Volz'; rbhibbs@pacbell.net; dhcwg@ietf.org Cc: 'Soohong Daniel Park' Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Hello Kostur Offhand I'm thinking that a Rapid Commit option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously. However I would suggest that the draft specify that by default DHCP Servers SHOULD have Rapid Reply disabled. => typo disabled / enabled correct ? Oh, and a minor comment: I think the option should be renamed to be "Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the inspiration of this option). => interesting. originally I tried to distinguish this option from option of dhcpv6. I will consider it. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics ------_=_NextPart_001_01C3A544.ACB30B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] FW: I-D = ACTION:draft-volz-dhc-rapidreply-opt-00.txt

No, I actually meant disabled.  Recall that DHCP = was designed to work in a scenario where there are multiple DHCP = servers performing offers to clients.  Rapid Commit/Reply is = basically a feature where you tell the service that there isn't = multiple DHCP servers (changing the default assumption in the = protocol).

So... by default all DHCP servers will work properly = in a multi-server environment unless it is explicitly told that it is = the only server that will be answering (where "only" may = include load-balanced and/or failover enabled pairs).

-----Original Message-----
From: Soohong Daniel Park [mailto:soohong.park@samsung.com= ]
Sent: Friday, November 07, 2003 12:08 AM
To: 'Kostur, Andre'; 'Bernie Volz'; = rbhibbs@pacbell.net; dhcwg@ietf.org
Cc: 'Soohong Daniel Park'
Subject: RE: [dhcwg] FW: I-D = ACTION:draft-volz-dhc-rapidreply-opt-00.txt


Hello Kostur
Offhand I'm thinking that a Rapid Commit option = would be handy, particularly in environments that may have a large = number of devices attempting to Discover simultaneously.  However = I would suggest that the draft specify that by default DHCP Servers = SHOULD have Rapid Reply disabled.

=3D> typo disabled / enabled  correct = ?
Oh, and a minor comment: I think the option should = be renamed to be "Rapid Commit" instead of Rapid Reply to be = consistent with DHCPv6 (which is the inspiration of this = option).

=3D> interesting. originally I tried to = distinguish this option from option of dhcpv6. I will consider = it.

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG = Electronics

------_=_NextPart_001_01C3A544.ACB30B40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 11:03:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20116; Fri, 7 Nov 2003 11:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI94g-0004za-0v; Fri, 07 Nov 2003 11:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI93z-0004wY-RU for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 11:02:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20084 for ; Fri, 7 Nov 2003 11:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI93x-0006pE-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 11:02:17 -0500 Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1AI93w-0006oX-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 11:02:16 -0500 Received: from entexchimc02.broadband.att.com (entexchimc02.broadband.att.com [147.191.89.201]) by peacock.tci.com (8.12.9/8.12.9) with ESMTP id hA7G1YTa013046 for ; Fri, 7 Nov 2003 09:01:44 -0700 (MST) Received: by entexchimc02.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 09:01:33 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0B6520EB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: dhcwg@ietf.org Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Fri, 7 Nov 2003 09:00:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Kevin is correct, for DOCSIS 1.0/1.1/2.0. See Annex D.1.1 of for DOCSIS use of DHCP fields. -- Rich -----Original Message----- From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] Sent: Friday, November 07, 2003 10:21 AM To: dhcwg@ietf.org Subject: RE: [dhcwg] IDs on remote boot support for DHCP To the best of my knowledge, DOCSIS still specifies the use of the 'file' field for booting cable modems. I've never seen 'sname' used. --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Barr Hibbs Sent: Thursday, 06 November, 2003 6:08 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] IDs on remote boot support for DHCP Ted-- Rob and I have already suggested that the use of the 'sname' and 'file' fields be not just deprecated, but removed from the DHCP packet format (see our I-D on RFC 2131 implementation issues that was discussed this morning in the WG meeting) to expand the 'options' field and eliminate all of that muck about overloading the 'sname' and 'file' fields. The big question is "are there ANY DHCP clients that use 'sname' and 'file' or options 66 and 67 to locate part of their boot images, or are all users of this feature BOOTP clients? --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Thursday, November 06, 2003 11:51 > > I've never heard of anybody using the sname field for anything. I'd > like to see its use deprecated, along with the server-name option. I > think we should have a single way of getting the identity of the server > to contact, not fifteen different ways (okay, I'm exaggerating, but you > get the idea). Otherwise, neither the administrator nor the client > implementor has any real way of anticipating which method to implement, > or which to prefer if multiple methods are offered and multiple methods > are implemented. So you wind up with the sysadmin playing a big > guessing game. Yuck. Frankly, I'm skeptical about any proposal to > add a new method in DHCPv4 for determining what file to load, or where > to load it - we should have a good reason for doing this, not just > "this way is better." > > > _______________________________________________ > 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-admin@ietf.org Fri Nov 7 12:28:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25678; Fri, 7 Nov 2003 12:28:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAOw-00022E-N8; Fri, 07 Nov 2003 12:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAOU-00021p-KP for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 12:27:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25637 for ; Fri, 7 Nov 2003 12:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAOT-00003O-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 12:27:33 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AIAOS-000032-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 12:27:32 -0500 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HNZ00J01ROD5E@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 12:27:02 -0500 (EST) Received: from kan1 (user127.net384.oh.sprint-hsd.net [65.40.69.127]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HNZ00FNBSH0B6@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 12:27:02 -0500 (EST) Date: Fri, 07 Nov 2003 12:27:01 -0500 From: "Kevin A. Noll" In-reply-to: <6732623D2548D61193C90002A5C88DCC0B6520EB@entmaexch02.broadband.att.com> To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [dhcwg] secs field? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Does anyone know if there are any BOOTP or DHCP server or relay implementations that actually make use of the 'secs' field? I know there are clients that update 'secs', but I don't know about any servers. Thanks. --kan-- -- Kevin A. Noll, KD4WOZ CCIE 10948, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 12:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26034; Fri, 7 Nov 2003 12:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAWf-0002jS-V3; Fri, 07 Nov 2003 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAW1-0002j1-IA for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 12:35:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25995 for ; Fri, 7 Nov 2003 12:35:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAVz-0000Bv-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 12:35:19 -0500 Received: from smtp100.mail.sc5.yahoo.com ([216.136.174.138]) by ietf-mx with smtp (Exim 4.12) id 1AIAVz-0000Bs-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 12:35:19 -0500 Received: from adsl-64-169-91-210.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.210 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Nov 2003 17:35:18 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] IDs on remote boot support for DHCP Date: Fri, 7 Nov 2003 09:34:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6732623D2548D61193C90002A5C88DCC0B6520EB@entmaexch02.broadband.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, Kevin-- thank you for clarifying that point --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Woundy, Richard > Sent: Friday, November 07, 2003 08:00 > To: dhcwg@ietf.org > Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > > Kevin is correct, for DOCSIS 1.0/1.1/2.0. > > See Annex D.1.1 of > for > DOCSIS use of DHCP fields. > > -- Rich > > -----Original Message----- > From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] > Sent: Friday, November 07, 2003 10:21 AM > To: dhcwg@ietf.org > Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > > > To the best of my knowledge, DOCSIS still specifies the use of the > 'file' field for booting cable modems. I've never seen 'sname' used. > > --kan-- > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Barr Hibbs > Sent: Thursday, 06 November, 2003 6:08 PM > To: dhcwg@ietf.org > Subject: RE: [dhcwg] IDs on remote boot support for DHCP > > > > Ted-- > > Rob and I have already suggested that the use of the 'sname' and 'file' > fields be not just deprecated, but removed from the DHCP packet > format (see > our I-D on RFC 2131 implementation issues that was discussed this > morning in > the WG meeting) to expand the 'options' field and eliminate all > of that muck > about overloading the 'sname' and 'file' fields. > > The big question is "are there ANY DHCP clients that use 'sname' > and 'file' > or options 66 and 67 to locate part of their boot images, or are all users > of this feature BOOTP clients? > > --Barr > > > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > > Lemon > > Sent: Thursday, November 06, 2003 11:51 > > > > I've never heard of anybody using the sname field for anything. I'd > > like to see its use deprecated, along with the server-name option. I > > think we should have a single way of getting the identity of the server > > to contact, not fifteen different ways (okay, I'm exaggerating, but you > > get the idea). Otherwise, neither the administrator nor the client > > implementor has any real way of anticipating which method to implement, > > or which to prefer if multiple methods are offered and multiple methods > > are implemented. So you wind up with the sysadmin playing a big > > guessing game. Yuck. Frankly, I'm skeptical about any proposal to > > add a new method in DHCPv4 for determining what file to load, or where > > to load it - we should have a good reason for doing this, not just > > "this way is better." > > > > > > _______________________________________________ > > 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-admin@ietf.org Fri Nov 7 13:12:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27380; Fri, 7 Nov 2003 13:12:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB5V-0004l2-Tn; Fri, 07 Nov 2003 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB4u-0004jS-Su for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 13:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27318 for ; Fri, 7 Nov 2003 13:11:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIB4s-0000e8-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:11:22 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AIB4s-0000e3-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:11:22 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 2278D1B226A; Fri, 7 Nov 2003 12:04:51 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] secs field? Date: Fri, 7 Nov 2003 12:11:17 -0600 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 7, 2003, at 11:27 AM, Kevin A. Noll wrote: > Does anyone know if there are any BOOTP or DHCP server or relay > implementations that actually make use of the 'secs' field? > > I know there are clients that update 'secs', but I don't know > about any servers. Both the ISC DHCP server and Nominum DCS are able to make use of the secs field as a way to override load balancing in cases where a client doesn't get any reply from the load balance server that should have given it a reply. This isn't required by the load balancing specification, IIRC, but I think you should have a pretty good reason for *not* doing it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 13:38:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28324; Fri, 7 Nov 2003 13:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBUg-0006CR-D9; Fri, 07 Nov 2003 13:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBUH-00064o-P5 for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 13:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28298 for ; Fri, 7 Nov 2003 13:37:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBUF-0000zV-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:37:35 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AIBUF-0000z9-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:37:35 -0500 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HNZ00201UQP8K@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 13:37:05 -0500 (EST) Received: from kan1 (user127.net384.oh.sprint-hsd.net [65.40.69.127]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HNZ00FG7VPRB6@endeavor.poss.com> for dhcwg@ietf.org; Fri, 07 Nov 2003 13:37:04 -0500 (EST) Date: Fri, 07 Nov 2003 13:37:03 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] secs field? In-reply-to: To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Thanks, Ted. On a related note, I've seen a certain OS vendor's DHCP client increment the secs field in the upper-order octet rather than the lower order. e.g. 28 secs = 00011100 00000000 Does anyone have any idea why it's used this way? Or perhaps my decoding of the field is incorrect? --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted Lemon Sent: Friday, 07 November, 2003 1:11 PM To: Kevin A. Noll Cc: dhcwg@ietf.org Subject: Re: [dhcwg] secs field? On Nov 7, 2003, at 11:27 AM, Kevin A. Noll wrote: > Does anyone know if there are any BOOTP or DHCP server or relay > implementations that actually make use of the 'secs' field? > > I know there are clients that update 'secs', but I don't know > about any servers. Both the ISC DHCP server and Nominum DCS are able to make use of the secs field as a way to override load balancing in cases where a client doesn't get any reply from the load balance server that should have given it a reply. This isn't required by the load balancing specification, IIRC, but I think you should have a pretty good reason for *not* doing it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 13:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28991; Fri, 7 Nov 2003 13:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBgI-0007R7-1o; Fri, 07 Nov 2003 13:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBfT-0007QE-EU for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 13:49:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28881 for ; Fri, 7 Nov 2003 13:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBfE-0001Ai-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:48:56 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AIBfD-0001AD-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 13:48:55 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hA7Im3Ar027824; Fri, 7 Nov 2003 13:48:12 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Kevin A. Noll'" , Subject: RE: [dhcwg] secs field? Date: Fri, 7 Nov 2003 13:48:03 -0500 Message-ID: <000001c3a55f$b0161820$6401a8c0@BVolz> 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.4510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is a byte ordering issue. htons isn't being used in the OS vendor's client to assure proper byte ordering. A trick that can be used (it does have risks) in a server is to check the value and if > 255 and the low order 8-bits are zero, assume that the bytes are out of order and swap them. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kevin A. Noll Sent: Friday, November 07, 2003 1:37 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] secs field? Thanks, Ted. On a related note, I've seen a certain OS vendor's DHCP client increment the secs field in the upper-order octet rather than the lower order. e.g. 28 secs = 00011100 00000000 Does anyone have any idea why it's used this way? Or perhaps my decoding of the field is incorrect? --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted Lemon Sent: Friday, 07 November, 2003 1:11 PM To: Kevin A. Noll Cc: dhcwg@ietf.org Subject: Re: [dhcwg] secs field? On Nov 7, 2003, at 11:27 AM, Kevin A. Noll wrote: > Does anyone know if there are any BOOTP or DHCP server or relay > implementations that actually make use of the 'secs' field? > > I know there are clients that update 'secs', but I don't know > about any servers. Both the ISC DHCP server and Nominum DCS are able to make use of the secs field as a way to override load balancing in cases where a client doesn't get any reply from the load balance server that should have given it a reply. This isn't required by the load balancing specification, IIRC, but I think you should have a pretty good reason for *not* doing it. _______________________________________________ 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-admin@ietf.org Fri Nov 7 17:10:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10346; Fri, 7 Nov 2003 17:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEnp-0005kQ-Ps; Fri, 07 Nov 2003 17:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2z4-0002kO-6g for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 04:32:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07183 for ; Fri, 7 Nov 2003 04:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2z1-0001r2-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:32:47 -0500 Received: from mail-in-02.arcor-online.net ([151.189.21.42]) by ietf-mx with esmtp (Exim 4.12) id 1AI2z0-0001qy-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:32:46 -0500 Received: from t4j6f1 (dialin-145-254-255-187.arcor-ip.net [145.254.255.187]) by mail-in-02.arcor-online.net (Postfix) with SMTP id 393BA11F1DA; Fri, 7 Nov 2003 10:32:39 +0100 (CET) Received: by localhost with Microsoft MAPI; Fri, 7 Nov 2003 10:33:46 +0100 Message-ID: <01C3A51A.9FB0C240.mrentsch@arcor.de> From: Markus Rentschler Reply-To: "mrentsch@arcor.de" To: "'dhcwg@ietf.org'" , "'rbhibbs@pacbell.net'" Subject: AW: [dhcwg] ID's: Interface Information Option Date: Fri, 7 Nov 2003 10:32:37 +0100 X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 Encoding: 57 TEXT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , [MR] comments inline.... > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Rentschler, Markus > Sent: Thursday, November 06, 2003 00:11 > > > > What benefit does this particular option give over simply using the > > existing Client Identifier (Opt 61) to encode such information? > > [MR>] There are several benefits: > > > > -- Another parameter for more tightly IP address allocation schemes for > > higher security. (The server configurator can for example say: a certain > > IP address/configuration is only allowed to a certain client > > (use MAC and /or Client-Id) on a certain location in the network topology > > (use Option 82) that is connected via a certain interface (use IIO). > > Any other useful combinations with other client's parameter as trigger > > conditions may be thought of... > > -- Possibility for topology discovery and therefore detection of > > misconfigured connections. > > ...you've obviously never had to manage an extremely large, widely dispersed client population with a diverse technician workforce. It is AN EXTREMELY BAD IDEA to try to "lock-down" devices by insisting on strict, unchanging relationships between MAC addresses, Client Identifiers, Host Names, hub, switch, or router ports, and other network elements. [MR] That might all be right in environments you are used to (office world ?). In some other areas there are completely different requirements! Dynamic adressing for example is hardly ever used in our field. Redundancy, security, tight control of everything in the network has a very high priority. Such networkers might be a minority, but does that really matter in this case? The principal benefit of DHCP is to reduce the need for detailed recordkeeping and configuration which represents a huge savings in labor costs, and reduced troubleshooting and repair times. Don't arbitrarily throw out that major benefit in the pursuit of the elusive goal of "improved security" -- [MR] Nothing is thrown out by adding a new option... when was the last time your organization, or ANY organization of which you had knowledge, was penetrated by someone plugging in an unauthorized network device? [MR] Even the possibility can make some people sleepless... Question: Why it is a goal of the dhcp wg to improve security, authentication and all that stuff if security doesn't really matter that much to you ;-) Best Regards, Markus _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 17:10:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10348; Fri, 7 Nov 2003 17:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEnr-0005kg-6Y; Fri, 07 Nov 2003 17:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3MK-0004j2-HJ for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 04:56:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08279 for ; Fri, 7 Nov 2003 04:56:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3MH-0002HS-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:56:49 -0500 Received: from mail-in-02.arcor-online.net ([151.189.21.42]) by ietf-mx with esmtp (Exim 4.12) id 1AI3MG-0002HP-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:56:48 -0500 Received: from t4j6f1 (dialin-145-254-255-187.arcor-ip.net [145.254.255.187]) by mail-in-02.arcor-online.net (Postfix) with SMTP id 0830A1316A2; Fri, 7 Nov 2003 10:56:48 +0100 (CET) Received: by localhost with Microsoft MAPI; Fri, 7 Nov 2003 10:57:56 +0100 Message-ID: <01C3A51D.FFF22600.mrentsch@arcor.de> From: Markus Rentschler Reply-To: "mrentsch@arcor.de" To: "'Soohong Daniel Park'" , "'Kostur, Andre'" , "'Bernie Volz'" , "rbhibbs@pacbell.net" , "dhcwg@ietf.org" Subject: AW: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Fri, 7 Nov 2003 10:57:42 +0100 X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 Encoding: 49 TEXT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I see the Rapid Reply/Commit Option as a useful thing and support what is said below. Best Regards, Markus -----Ursprungliche Nachricht----- Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] Gesendet am: Freitag, 7. November 2003 09:08 An: 'Kostur, Andre'; 'Bernie Volz'; rbhibbs@pacbell.net; dhcwg@ietf.org Cc: 'Soohong Daniel Park' Betreff: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > ---------- > From: Soohong Daniel Park[SMTP:SOOHONG.PARK@SAMSUNG.COM] > Sent: Friday, November 07, 2003 9:08:23 AM > To: 'Kostur, Andre'; 'Bernie Volz'; rbhibbs@pacbell.net; > dhcwg@ietf.org > Cc: 'Soohong Daniel Park' > Subject: RE: [dhcwg] FW: I-D > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > Auto forwarded by a Rule > Hello Kostur Offhand I'm thinking that a Rapid Commit option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously. However I would suggest that the draft specify that by default DHCP Servers SHOULD have Rapid Reply disabled. => typo disabled / enabled correct ? Oh, and a minor comment: I think the option should be renamed to be "Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the inspiration of this option). => interesting. originally I tried to distinguish this option from option of dhcpv6. I will consider it. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics << Datei: ATT00002.htm >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 7 18:00:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10347; Fri, 7 Nov 2003 17:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEnq-0005kY-HH; Fri, 07 Nov 2003 17:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI397-0003jS-5q for dhcwg@optimus.ietf.org; Fri, 07 Nov 2003 04:43:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07809 for ; Fri, 7 Nov 2003 04:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI393-00026a-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:43:09 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AI393-00024r-00 for dhcwg@ietf.org; Fri, 07 Nov 2003 04:43:09 -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 hA79gQpI027849; Fri, 7 Nov 2003 10:42:27 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hA79gQR7030166; Fri, 7 Nov 2003 10:42:26 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hA79gNbf030165; Fri, 7 Nov 2003 10:42:23 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 7 Nov 2003 10:42:23 +0100 From: Stig Venaas To: Martin Stiemerling Cc: Ron Lee , dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 server availability Message-ID: <20031107094223.GD30008@sverresborg.uninett.no> References: <000001c3a43c$2e1cfab0$885bd5a5@LocalHost> <2887942.1068199950@[10.1.1.109]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2887942.1068199950@[10.1.1.109]> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, Nov 07, 2003 at 10:12:30AM +0100, Martin Stiemerling wrote: > Hi, > > --On Donnerstag, 6. November 2003 17:01 +0900 Ron Lee > wrote: > > | > | Hello, I am wondering which companies have implemented DHCPv6 server. > > You probably have to ask the companies directly. But how to ask them if you don't know which? Well, I suppose the relevant companies have people following this mailing list, so they would hopefully reveal themself if ready... Several people are looking for DHCPv6 servers to try, and we all know that there are some implementations out there, but we don't know which, and we can't get access to them it looks like. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Nov 8 05:40:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12364; Sat, 8 Nov 2003 05:40:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIQVf-0007n8-1z; Sat, 08 Nov 2003 05:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIQVD-0007m3-1U for dhcwg@optimus.ietf.org; Sat, 08 Nov 2003 05:39:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12344 for ; Sat, 8 Nov 2003 05:39:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIQV9-00051n-00 for dhcwg@ietf.org; Sat, 08 Nov 2003 05:39:31 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1AIQV8-00051k-00 for dhcwg@ietf.org; Sat, 08 Nov 2003 05:39:30 -0500 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 2649534; Sat, 08 Nov 2003 11:39:30 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: "Kevin A. Noll" Subject: Re: [dhcwg] secs field? Date: Sat, 8 Nov 2003 11:41:53 +0100 User-Agent: KMail/1.4.3 References: In-Reply-To: Cc: dhcwg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200311081141.53093.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Friday 07 November 2003 18.27, Kevin A. Noll wrote: > Does anyone know if there are any BOOTP or DHCP server or relay > implementations that actually make use of the 'secs' field? Our DHCP server has a $SECS() function that can return this value at runt= ime,=20 where it can be used in all sorts of decisions. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 9 15:29:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09560; Sun, 9 Nov 2003 15:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwBB-00037X-HH; Sun, 09 Nov 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuqb-00084K-Ia for dhcwg@optimus.ietf.org; Sun, 09 Nov 2003 14:03:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06690 for ; Sun, 9 Nov 2003 14:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuqZ-0005b1-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 14:03:39 -0500 Received: from bay4-f3.bay4.hotmail.com ([65.54.171.3] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AIuqY-0005as-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 14:03:38 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Nov 2003 11:03:05 -0800 Received: from 130.129.135.237 by by4fd.bay4.hotmail.msn.com with HTTP; Sun, 09 Nov 2003 19:03:05 GMT X-Originating-IP: [130.129.135.237] X-Originating-Email: [natpt@msn.com] From: "soohong park" To: Stephane.Antoine@panasonicmobile.co.uk Cc: dhcwg@ietf.org, soohong.park@samsung.com Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Mon, 10 Nov 2003 04:03:05 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Nov 2003 19:03:05.0761 (UTC) FILETIME=[1B59D910:01C3A6F4] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello Stephane >It is a good idea, dhcp is ok to give IP addressses in the wireless >environment Yep >but it is not optimised for mobility! "supported for mobility" would be better than optimised. Correct ? Regards Daniel (Soohong Daniel Park) _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 13:21:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04008; Mon, 10 Nov 2003 13:21:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGet-0006tR-PJ; Mon, 10 Nov 2003 13:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGe6-0006s5-UO for dhcwg@optimus.ietf.org; Mon, 10 Nov 2003 13:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03944 for ; Mon, 10 Nov 2003 13:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGe4-0001dM-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 13:20:12 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AJGe4-0001cW-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 13:20:12 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119076>; Mon, 10 Nov 2003 19:11:52 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Nov 2003 19:19:22 +0100 Message-ID: From: "Rentschler, Markus" To: "Kostur, Andre" , dhcwg@ietf.org Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions Date: Mon, 10 Nov 2003 19:19:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable [MR>] Comments inline... > -----Urspr=FCngliche Nachricht----- > Von: Kostur, Andre [SMTP:Andre@incognito.com] > Gesendet am: Donnerstag, 6. November 2003 18:03 > An: 'Rentschler, Markus'; Kostur, Andre; dhcwg@ietf.org > Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions >=20 > > If the Discovery Extensions are supported, the acceptance of = > > DHCPCONFIGURE should be configurable. Additionally initial sending = of=20 > > DHCPDISCOVER should be configurable.=20 >=20 > Are you therefore saying that devices will have DHCPCONFIGURE = disabled by > default? As well as sending an initial DHCPDISCOVER? (So by default = the > client does _nothing_ on bootup?) >=20 [MR>] That wouldn't be useful. Of course at least one of the mechanisms should be enabled. I suggest that by default both should be enabled. =20 > > No additional states in the client's state machine required.=20 > Not true. There are a bunch more state transitions, and at least one = more > state where the device has received a DHCPCONFIGURE causing it to > transition into a new State where the device emits a DHCPRELEASE and > transitions into another state where it emits a DHCPREPORT, where = then it > finally transitions back into the Bound state. Plus whatever state > transitions and states would be needed to express what the client is = to do > when it receives a NETSCAN in each state. >=20 [MR>] What you mean, could at most be described "transitional states": An external event (DHCPNETSCAN, DHCPCONFIGURE) triggers = immediate actions (DHCPREPORT and internal things ). That are no stable states, = whose values are kept in some state variable.=20 Under a "state" i understand a stable state that waits for some (external) event to change the state variable's value.=20 This is not the case with the Discovery Extensions. > Another thought... what happens if the device sends the RELEASE, then > sends the REPORT, but the REPORT is lost? (keep in mind that this is = all > UDP... UDP packets may get dropped). >=20 [MR>] Then the server will have to retransmit its DHCPCONFIGURE until it gets a DHCPREPORT from that device.=20 Since this is done on layer 2, it is not important if the device accepted the initial DHCPCONFIGURE or still uses it's old or no ip = address at all. =20 > > [MR>]=20 > > Both should be possible: configuration AND reconfiguration,=20 > We already have a mechanism for reconfiguration. Why reinvent the = wheel, > which only adds additional overhead?=20 >=20 [MR>] Sure, but there is no mechanism for server-originated CONfiguration. That's what the draft is all about. [MR>] =20 > However your draft specifies that the default behaviour is to cause > broadcast storms across your entire network (and it even goes so far = as to > suggest doing it periodically). So, there's two possiblities here. = One > is that DHCPCONFIGURE is enabled on clients by default, thus only one > mildly malicious user can emit a NETSCAN once an hour and cause your > entire network of 200000 devices to DDoS your real DHCP server by > hammering it with 200000 REPORTs, >=20 [MR>] That is the only point that makes me some headache too.=20 I would like to get some ideas how this potential danger could be minimised. With normal DHCP we got a similar Problem at bootup, when every client emits it DHCPDISCOVER messages. > > > OK, what happens in the case:=20 > > > 1) Device A sends the RELEASE=20 > > > 2) Device B Discovers & Requests (since the IP is now=20 > > available, it was=20 > > > just released!) the now released IP=20 > > > 3) Device A REPORTs on that IP=20 > > > ?=20 > > [MR>] =20 > > The REPORT must of course use the new IP assigned with=20 > > DHCPCONFIGURE, since it is the REPORT's main job to tell the=20 > > rest of the network that a certain client has a certain = configuration. =20 > > So there should be no problem.=20 > There's a big problem. There is now two devices with the same IP = address. >=20 >=20 [MR>]=20 How do you get that idea ??=20 Device A has released the IP, since it got a DHCPCONFIGURE=20 with new settings AND accepted them (Otherwise there would be no RELEASE). So only Device B has this IP. > > The philosophy of the Discovery Extensions are: "The=20 > > client provides=20 > > means that the server can use if he wishes." The client only reacts = to=20 > > actions from the server.=20 > Which is a fundamental change in the DHCP protocol. Currently it's = the > service that only reacts to actions from the clients (notwithstanding > 3203). >=20 [MR>] I would rather put it that way: =20 It is a fundamental EXTENSION to the DHCP protocol :-) > network), using the=20 > FROCERENEW mechanism would mean a four message exchange for every client!! =20 Three message exchange, BTW: FORCERENEW->REQUEST->ACK=20 [MR>] You're right, of course. > > The Discovery Extensions are a different approach,=20 > > please keep this in mind. One shouldn't compare them too much to=20 > > client-originated DHCP since they follow different philosophies.=20 >=20 > Then it is a different protocol, and should be treated as such.=20 >=20 [MR>] It does the same (configuring the client with ip and some other parameters),=20 just in a slightly different way that offers some additional opprtunities for network administrators. Regards, Markus _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 13:53:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05370; Mon, 10 Nov 2003 13:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH9p-00012I-OU; Mon, 10 Nov 2003 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH9E-0000wJ-1D for dhcwg@optimus.ietf.org; Mon, 10 Nov 2003 13:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05270 for ; Mon, 10 Nov 2003 13:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH9B-0002BV-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 13:52:21 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AJH9A-0002AQ-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 13:52:20 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AJH8O-00056y-00; Mon, 10 Nov 2003 10:51:32 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5XLAR>; Mon, 10 Nov 2003 10:51:25 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Mon, 10 Nov 2003 10:51:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A7BB.A3BD9720" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A7BB.A3BD9720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > -----Urspr=FCngliche Nachricht----- > > Von: Kostur, Andre [SMTP:Andre@incognito.com] > > Gesendet am: Donnerstag, 6. November 2003 18:03 > > An: 'Rentschler, Markus'; Kostur, Andre; dhcwg@ietf.org > > Betreff: RE: [dhcwg] ID's: DHCP Discovery Extensions > >=20 > > > If the Discovery Extensions are supported, the=20 > acceptance of=20 > > > DHCPCONFIGURE should be configurable. Additionally=20 > initial sending of=20 > > > DHCPDISCOVER should be configurable.=20 > >=20 > > Are you therefore saying that devices will have=20 > DHCPCONFIGURE disabled by > > default? As well as sending an initial DHCPDISCOVER? (So=20 > by default the > > client does _nothing_ on bootup?) > >=20 > [MR>] That wouldn't be useful. Of course at least one of the > mechanisms should be enabled. I suggest that by default both should = be > enabled. Thus by default, any device on the network would be able to trigger a = DDoS attack on your DHCP infrastructure by sending a broadcast DHCPNETSCAN (again, we're talking about the proposed _default_ configuration)? Oops.... reading the draft again... it actually specifies that = DHCPCONFIGURE SHOULD be disabled by default. My oversight. Which does mean that an administrator would have to visit every device in order to enable DHCPCONFIGURE. In which case, why doesn't the admin simply enable DHCP = to begin with. This would make DHCPCONFIGURE redundant (the device will already have a lease, or will DISCOVER soon. And accept FORCERENEW (assuming RFC 3203 is implemented) ). > > > No additional states in the client's state machine=20 > required.=20 > > Not true. There are a bunch more state transitions, and at=20 > least one more > > state where the device has received a DHCPCONFIGURE causing it to > > transition into a new State where the device emits a DHCPRELEASE = and > > transitions into another state where it emits a DHCPREPORT,=20 > where then it > > finally transitions back into the Bound state. Plus whatever state > > transitions and states would be needed to express what the=20 > client is to do > > when it receives a NETSCAN in each state. > >=20 > [MR>] What you mean, could at most be described "transitional > states": An external event (DHCPNETSCAN, DHCPCONFIGURE)=20 > triggers immediate > actions (DHCPREPORT and internal things ). That are no stable=20 > states, whose > values are kept in some state variable.=20 > Under a "state" i understand a stable state that waits for some > (external) event to change the state variable's value.=20 > This is not the case with the Discovery Extensions. The draft still has additional state transitions to document. For = example: upon receiving a DHCPNETSCAN in the BOUND state, the client must = transmit a DHCPREPORT and transition back to the BOUND state. Upon receiving a DHCPNETSCAN in the INIT-REBOOT state, do what? How about SELECTING? = The draft is proposing 3 new messages. The draft needs to document what is going to happen in _every_ state of the DHCP client state machine when = it receives any of the 3 messages (OK, 2 messages, clients shouldn't be = getting REPORTs). Offhand, I think there's still a state in there between sending a DHCPRELEASE, and sending the DHCPREPORT. I don't think you can have 1 = state transition sending two messages (at least there are no current state transitions which emit 2 messages....) > > Another thought... what happens if the device sends the=20 > RELEASE, then > > sends the REPORT, but the REPORT is lost? (keep in mind=20 > that this is all > > UDP... UDP packets may get dropped). > >=20 > [MR>] Then the server will have to retransmit its DHCPCONFIGURE > until it gets a DHCPREPORT from that device.=20 > Since this is done on layer 2, it is not important if the device > accepted the initial DHCPCONFIGURE or still uses it's old or=20 > no ip address > at all. However, in the meantime there's a DHCP device out there that has an IP address, which the DHCP server has no valid lease for. This opens up = the possibility of duplicate IP address allocation. > > > [MR>]=20 > > > Both should be possible: configuration AND reconfiguration, = > > We already have a mechanism for reconfiguration. Why=20 > reinvent the wheel, > > which only adds additional overhead?=20 > >=20 > [MR>] Sure, but there is no mechanism for server-originated > CONfiguration. That's what the draft is all about. If the device is configured to use DHCP anyway, you only need to wait = until the device performs a DISCOVER. Configuring a device to use DHCP to = begin with is beyond the scope of DHCP. > [MR>] =20 > > However your draft specifies that the default behaviour is to cause > > broadcast storms across your entire network (and it even=20 > goes so far as to > > suggest doing it periodically). So, there's two=20 > possiblities here. One > > is that DHCPCONFIGURE is enabled on clients by default,=20 > thus only one > > mildly malicious user can emit a NETSCAN once an hour and cause = your > > entire network of 200000 devices to DDoS your real DHCP server by > > hammering it with 200000 REPORTs, > >=20 > [MR>] That is the only point that makes me some headache too.=20 > I would like to get some ideas how this potential=20 > danger could be > minimised. > With normal DHCP we got a similar Problem at bootup, when every > client emits it DHCPDISCOVER messages. Granted, if your entire network is rebooting, the servers will undergo = a severe load. However this would (hopefully) be a fairly rare event. = With this proposed draft, it even suggests initiating this load on a = periodic basis! > > > > OK, what happens in the case:=20 > > > > 1) Device A sends the RELEASE=20 > > > > 2) Device B Discovers & Requests (since the IP is now=20 > > > available, it was=20 > > > > just released!) the now released IP=20 > > > > 3) Device A REPORTs on that IP=20 > > > > ?=20 > > > [MR>] =20 > > > The REPORT must of course use the new IP assigned with=20 > > > DHCPCONFIGURE, since it is the REPORT's main job to tell the=20 > > > rest of the network that a certain client has a certain=20 > configuration. =20 > > > So there should be no problem.=20 > > There's a big problem. There is now two devices with the=20 > same IP address. > >=20 > >=20 > [MR>]=20 > How do you get that idea ??=20 > Device A has released the IP, since it got a DHCPCONFIGURE=20 > with new settings AND accepted them (Otherwise there would be no > RELEASE). > So only Device B has this IP. Not necessarily true. Device A gets a DHCPCONFIGURE to change it's DNS settings. Since Device A has a current lease, the draft says that it = needs to DHCPRELEASE it first. Now the DHCP server has released the IP, but = the client is still using the IP. Device B comes and does a = DISCOVER/REQUEST, receiving that IP. Presto, duplicate IP. > > > The philosophy of the Discovery Extensions are: "The=20 > > > client provides=20 > > > means that the server can use if he wishes." The client=20 > only reacts to=20 > > > actions from the server.=20 > > Which is a fundamental change in the DHCP protocol. =20 > Currently it's the > > service that only reacts to actions from the clients=20 > (notwithstanding > > 3203). > >=20 > [MR>] I would rather put it that way: =20 > It is a fundamental EXTENSION to the DHCP protocol :-) >=20 > > network), using the=20 > > FROCERENEW mechanism would mean a four message=20 > exchange for every > client!! =20 > Three message exchange, BTW: FORCERENEW->REQUEST->ACK=20 >=20 > [MR>] You're right, of course. >=20 >=20 > > > The Discovery Extensions are a different approach,=20 > > > please keep this in mind. One shouldn't compare them too much to=20 > > > client-originated DHCP since they follow different philosophies.=20 > >=20 > > Then it is a different protocol, and should be treated as such.=20 > >=20 > [MR>] It does the same (configuring the client with ip and some > other parameters),=20 > just in a slightly different way that offers some additional > opprtunities for network administrators. So far, I don't see the advantage of using this particular scheme over = the already specified RFC 3203. I think that 3203 has some elegance in it = that it reuses as much of the existing DHCP infrastructure as possible. = Instead of the FORCERENEW attempting to do everything, it only triggers the = client to renew immediately, instead of waiting for the full lease time. = Results in the client doing a unicast RENEW, which if all you're changing is = the DNS settings, the client could easily only change the DNS settings = resulting in as little disruption to IP services as possible (client implementation detail...). And if you're chaging the IP settings, the device would = get a normal NAK to the request, causing the client to perform all the normal = DHCP behaviours associated with the NAK. This draft seems to imply that a device _must_ have a DHCP state = machine running, even if the device isn't going to be using DHCP. If the = device is already using DHCP, then this draft is redundant with other, already specified behaviours (Failover, RFC 3203, RFC 2131) (Again, if the = device is already using DHCP, it will DISCOVER on it's own, or it will have an established lease). ------_=_NextPart_001_01C3A7BB.A3BD9720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: DHCP Discovery Extensions

> > -----Urspr=FCngliche Nachricht-----
> > = Von:        Kostur, Andre = [SMTP:Andre@incognito.com]
> > Gesendet = am:        Donnerstag, 6. November = 2003 18:03
> > An: 'Rentschler, Markus'; Kostur, Andre; = dhcwg@ietf.org
> > Betreff:    RE: [dhcwg] = ID's: DHCP Discovery Extensions
> >
> > >       = If the  Discovery Extensions are supported, the
> acceptance of
> > > DHCPCONFIGURE should be configurable. = Additionally
> initial sending of
> > > DHCPDISCOVER should be configurable. =
> >
> > Are you therefore saying that devices will = have
> DHCPCONFIGURE disabled by
> > default?  As well as sending an = initial DHCPDISCOVER?  (So
> by default the
> > client does _nothing_ on bootup?)
> >
>       [MR>]  = That wouldn't be useful. Of course at least one of the
> mechanisms should be enabled. I suggest that by = default both should be
> enabled.

Thus by default, any device on the network would be = able to trigger a DDoS attack on your DHCP infrastructure by sending a = broadcast DHCPNETSCAN (again, we're talking about the proposed = _default_ configuration)?

Oops.... reading the draft again... it actually = specifies that DHCPCONFIGURE SHOULD be disabled by default.  My = oversight.  Which does mean that an administrator would have to = visit every device in order to enable DHCPCONFIGURE.  In which = case, why doesn't the admin simply enable DHCP to begin with.  = This would make DHCPCONFIGURE redundant (the device will already have a = lease, or will DISCOVER soon.  And accept FORCERENEW (assuming RFC = 3203 is implemented) ).

> > >       No = additional states in the client's state machine
> required.
> > Not true.  There are a bunch more = state transitions, and at
> least one more
> > state where the device has received a = DHCPCONFIGURE causing it to
> > transition into a new State where the = device emits a DHCPRELEASE and
> > transitions into another state where it = emits a DHCPREPORT,
> where then it
> > finally transitions back into the Bound = state.  Plus whatever state
> > transitions and states would be needed to = express what the
> client is to do
> > when it receives a NETSCAN in each = state.
> >
>       [MR>]  = What you mean, could at most be described "transitional
> states": An external event (DHCPNETSCAN, = DHCPCONFIGURE)
> triggers immediate
> actions (DHCPREPORT and internal things ). That = are no stable
> states, whose
> values are kept in some state variable.
>       Under a = "state" i understand a stable state that waits for = some
> (external) event to change the state variable's = value.
>       This is not the = case with the Discovery Extensions.

The draft still has additional state transitions to = document.  For example: upon receiving a DHCPNETSCAN in the BOUND = state, the client must transmit a DHCPREPORT and transition back to the = BOUND state.  Upon receiving a DHCPNETSCAN in the INIT-REBOOT = state, do what?   How about SELECTING?  The draft is = proposing 3 new messages.  The draft needs to document what is = going to happen in _every_ state of the DHCP client state machine when = it receives any of the 3 messages (OK, 2 messages, clients shouldn't be = getting REPORTs).

Offhand, I think there's still a state in there = between sending a DHCPRELEASE, and sending the DHCPREPORT.  I = don't think you can have 1 state transition sending two messages (at = least there are no current state transitions which emit 2 = messages....)

> > Another thought... what happens if the = device sends the
> RELEASE, then
> > sends the REPORT, but the REPORT is = lost?  (keep in mind
> that this is all
> > UDP... UDP packets may get = dropped).
> >
>       [MR>]  = Then the server will have to retransmit its DHCPCONFIGURE
> until it gets a DHCPREPORT from that device. =
>       Since this is = done on layer 2, it is not important if the device
> accepted the initial DHCPCONFIGURE or still = uses it's old or
> no ip address
> at all.

However, in the meantime there's a DHCP device out = there that has an IP address, which the DHCP server has no valid lease = for.  This opens up the possibility of duplicate IP address = allocation.

> > >       = [MR>]
> > >       = Both should be possible: configuration AND reconfiguration,
> > We already have a mechanism for = reconfiguration.  Why
> reinvent the wheel,
> > which only adds additional overhead? =
> >
>       [MR>]  = Sure, but there is no mechanism for server-originated
> CONfiguration. That's what the draft is all = about.

If the device is configured to use DHCP anyway, you = only need to wait until the device performs a DISCOVER.  = Configuring a device to use DHCP to begin with is beyond the scope of = DHCP.

>       [MR>]  =
> > However your draft specifies that the = default behaviour is to cause
> > broadcast storms across your entire = network (and it even
> goes so far as to
> > suggest doing it periodically).  So, = there's two
> possiblities here.  One
> > is that DHCPCONFIGURE is enabled on = clients by default,
> thus only one
> > mildly malicious user can emit a NETSCAN = once an hour and cause your
> > entire network of 200000 devices to DDoS = your real DHCP server by
> > hammering it with 200000 REPORTs,
> >
>       [MR>]  = That is the only point that makes me some headache too.
>       I would like to = get some ideas how this potential
> danger could be
> minimised.
>       With normal DHCP = we got a similar Problem at bootup, when every
> client emits it DHCPDISCOVER messages.

Granted, if your entire network is rebooting, the = servers will undergo a severe load.  However this would = (hopefully) be a fairly rare event.  With this proposed draft, it = even suggests initiating this load on a periodic basis!

> > > > OK, what happens in the case: =
> > > > 1) Device A sends the RELEASE =
> > > > 2) Device B Discovers & = Requests (since the IP is now
> > > available, it was
> > > > just released!) the now released = IP
> > > > 3) Device A REPORTs on that IP =
> > > > ?
> > >       = [MR>] 
> > >       = The REPORT must of course use the new IP assigned with
> > > DHCPCONFIGURE, since it is the = REPORT's main job to tell the
> > > rest of the network that a certain = client has a certain
> configuration. 
> > > So there should be no problem. =
> > There's a big problem.  There is now = two devices with the
> same IP address.
> >
> >
>       [MR>]
>       How do you get = that idea ??
>       Device A has = released the IP, since it got a DHCPCONFIGURE
>       with new = settings AND accepted them (Otherwise there would be no
> RELEASE).
>       So only Device B = has this IP.

Not necessarily true.  Device A gets a = DHCPCONFIGURE to change it's DNS settings.  Since Device A has a = current lease, the draft says that it needs to DHCPRELEASE it = first.  Now the DHCP server has released the IP, but the client is = still using the IP.  Device B comes and does a DISCOVER/REQUEST, = receiving that IP.  Presto, duplicate IP.

> > >       = The philosophy of the Discovery Extensions are: "The
> > > client provides
> > > means that the server can use if he = wishes." The client
> only reacts to
> > > actions from the server.
> > Which is a fundamental change in the DHCP = protocol. 
> Currently it's the
> > service that only reacts to actions from = the clients
> (notwithstanding
> > 3203).
> >
>       [MR>]  I = would rather put it that way: 
>       It is a = fundamental EXTENSION to the DHCP protocol  :-)
>
>       > network), = using the
>       > FROCERENEW = mechanism would mean a four message
> exchange for every
> client!!   
>        Three = message exchange, BTW: FORCERENEW->REQUEST->ACK
>
>       [MR>]  = You're right, of course.
>
>
> > >       = The Discovery Extensions are a different approach,
> > > please keep this in mind. One = shouldn't compare them too much to
> > > client-originated DHCP since they = follow different philosophies.
> >
> > Then it is a different protocol, and = should be treated as such.
> >
>       [MR>]  = It does the same (configuring the client with ip and some
> other parameters),
>       just in a = slightly different way that offers some additional
> opprtunities for network administrators.

So far, I don't see the advantage of using this = particular scheme over the already specified RFC 3203.  I think = that 3203 has some elegance in it that it reuses as much of the = existing DHCP infrastructure as possible.  Instead of the = FORCERENEW attempting to do everything, it only triggers the client to = renew immediately, instead of waiting for the full lease time.  = Results in the client doing a unicast RENEW, which if all you're = changing is the DNS settings, the client could easily only change the = DNS settings resulting in as little disruption to IP services as = possible (client implementation detail...).  And if you're chaging = the IP settings, the device would get a normal NAK to the request, = causing the client to perform all the normal DHCP behaviours associated = with the NAK.


This draft seems to imply that a device _must_ have a = DHCP state machine running, even if the device isn't going to be using = DHCP.   If the device is already using DHCP, then this draft = is redundant with other, already specified behaviours (Failover, RFC = 3203, RFC 2131)  (Again, if the device is already using DHCP, it = will DISCOVER on it's own, or it will have an established = lease).

------_=_NextPart_001_01C3A7BB.A3BD9720-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 16:06:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13523; Mon, 10 Nov 2003 16:06:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJEX-0002g2-JJ; Mon, 10 Nov 2003 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJDz-0002fK-UT for dhcwg@optimus.ietf.org; Mon, 10 Nov 2003 16:05:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13487 for ; Mon, 10 Nov 2003 16:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJDy-0004eX-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 16:05:26 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AJJDx-0004eU-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 16:05:25 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 0967F1C02ADF; Mon, 10 Nov 2003 13:05:24 -0800 (PST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA00415; Tue, 11 Nov 2003 02:34:08 +0530 (IST) Message-ID: <3FAFFD91.6040008@india.hp.com> Date: Tue, 11 Nov 2003 02:35:21 +0530 From: Senthil Kumar B Organization: Hewlett Packard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] ID on Proxy Server Configuration using DHCP References: <200311042029.BAA06679@iconsrv5.india.hp.com> <21479.1068025629@munnari.OZ.AU> In-Reply-To: <21479.1068025629@munnari.OZ.AU> Content-Type: multipart/alternative; boundary="------------010107000604030000010309" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------010107000604030000010309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert, Thanks for your comments. I am not very sure of any clients implementing/implemented these options. This is not just for the browsers. This would be needed for any clients, which MUST go through a proxy for any type of activity. For example, within an enterprise network, if a client lies behind a firewall and wants to access some resource for which a firewall/proxy access is required. Also, I have seen some application which installs over the net and require proxy configuration for proper access to the external network This is either to provide controlled access (in most of the cases, using firewall) and/or for efficient access using caching and other mechanism. The client might require a system parameter, which can be used till the machine reboots. Also, the preferred things is to have a modifiable parameter so that any change would be in effect immediately. Is it that Proxy config using an URL format is of the form http:/proxy.xxx.yy.com:8080 ? or any another format. As long as the the server provides a method to have a proxy configuration and it is of easy for the client to configure, any type of configuration is fine. Please give your comments on this if you have any. Thanks, Senthil Robert Elz wrote: >This is the kind of option that has been needed for ages. > >I'd be interested in knowing if it is likely that any clients >(browsers in particular) are likely to support it, or what would >be needed for them to support it - the option will be useless if >it isn't used. > >I'll leave the DHCP details for someone more expert in DHCP than I >to comment on - though my impression is that most proxy >configuration is done using a URL format, and I'd wonder if perhaps >the config that is wanted for a proxy shouldn't be a URL, rather >than a binary address & port number. > >kre > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > --------------010107000604030000010309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Robert,

Thanks for your comments. I am not very sure of any clients implementing/implemented these options.
This is not just for the browsers. This would be needed for any clients, which MUST go through a
proxy for any type of activity. For example, within an  enterprise network, if a client lies behind a firewall
and wants to access some resource for which a firewall/proxy access is required.

Also, I have seen some application which installs over the net and require proxy configuration for proper
access to the external network This is either to provide controlled access (in most of the cases, using firewall)
and/or for efficient access using caching and other mechanism.

The client might require a system parameter, which can be used till the machine reboots.
Also, the preferred things is to have a modifiable parameter so that any change would be in effect immediately.

Is it that Proxy config using an URL format is of the form http:/proxy.xxx.yy.com:8080 ?
or any another format. As long as the the server provides a method to have a proxy configuration
and it is of easy for the client to configure,  any type of configuration is fine.
Please give your comments on this if you have any.

Thanks,
Senthil

Robert Elz wrote:
This is the kind of option that has been needed for ages.

I'd be interested in knowing if it is likely that any clients
(browsers in particular) are likely to support it, or what would
be needed for them to support it - the option will be useless if
it isn't used.

I'll leave the DHCP details for someone more expert in DHCP than I
to comment on - though my impression is that most proxy
configuration is done using a URL format, and I'd wonder if perhaps
the config that is wanted for a proxy shouldn't be a URL, rather
than a binary address & port number.

kre


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--------------010107000604030000010309-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 16:10:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13687; Mon, 10 Nov 2003 16:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJIQ-00036S-Jg; Mon, 10 Nov 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJHb-00035r-M1 for dhcwg@optimus.ietf.org; Mon, 10 Nov 2003 16:09:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13648 for ; Mon, 10 Nov 2003 16:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJHZ-0004hq-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 16:09:09 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AJJHZ-0004hn-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 16:09:09 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id 034E51C03674; Mon, 10 Nov 2003 16:09:08 -0500 (EST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA00621; Tue, 11 Nov 2003 02:37:51 +0530 (IST) Message-ID: <3FAFFE70.2070105@india.hp.com> Date: Tue, 11 Nov 2003 02:39:04 +0530 From: Senthil Kumar B Organization: Hewlett Packard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: Re: [dhcwg] ID on Proxy Server Configuration using DHCP References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040104090000090109080201" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040104090000090109080201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barr, Thanks for your comments. Please see my reply inline. Barr Hibbs wrote: >I think this proposed option and set of sub-options is both unnecessary and >unlikely to be used. I base my opinion on the existence of three current >DHCP options that are not, to my knowledge, used at all: > > option 72 -- Default World Wide Web (WWW) Server > option 73 -- Default Finger Server > option 74 -- Default Internet Relay Chat (IRC) Server > >To be sure of my position, I configured two of the most widely used DHCP >servers with option 72 data, then released existing DHCP leases and rebooted >hosts using two different DHCP clients and two different web browsers, >monitoring the data exchange with Ethereal. Neither client requested option >72 from the server and neither server sent the option without being >requested. When the web browsers were started, neither one issued a >DHCPINFORM message requesting option 72. > >Perhaps someone could come forward with a justification for these three >options? > >Of course the DHC Working Group could define a means for configuring a >client with proxy server information, but I fear it would be like options >72, 73, and 74 -- unused. > I have explained the situation (in my earlier reply to Robert Elz) where this proxy config option could be useful. I do support that there are so many options like (72 to 74) which are not actively being used. >The key to success is to have DHCP client vendors as well as applications >vendors committed to using the option and sub-options if the DHC Working >Group were to define them. > >I also object to this wording, found in section 4 of the draft: > > "More than one Sub Option MAY be specified for the same protocol. > In that case, the precedence MUST be given in the order in which > these options were received by the client. The first one received > shall be given higher priority and so on." > >I know of no other DHCP option in which the order of receipt mandates the >priority for use by the client, and I don't think this is a good precedent >to establish without a compelling reason to do so. Consider the routers >(03) option: > > "The router option specifies a list of IP addresses for routers on the > client's subnet. Routers SHOULD be listed in order of preference." > >There is only a recommendation ("SHOULD") that a client receiving this >option choose which router to use for subsequent IP messages according to >the order of appearance in the router option. A client is free to choose >whichever router it wishes for future messages, possibly applying some other >information in making the choice. I believe this is a very good model to >follow. > I agree that it shouldn't be MUST. Should be SHOULD. I didn't intend to write MUST here. It was my mistake and my apologies for the confusion. Thanks a lot for the determinations. >"Security Considerations," section 8, contains this statement: > > "The DHCP Options defined here allow an unauthorized DHCP server to > misdirect a client to access nonexistent/erring Proxy Server due to > which the connection to the Internet might be denied." > >Yes, but every other option presents an opportunity to misconfigure a >client, either unintentionally or maliciously. The word "unauthorized" >implies that there is such a thing as an "authorized" DHCP server, which is >both incorrect and misleading. > I will update the doc with "interloper" DHCP server instead of "unauthorized" DHCP server in section 8. >____________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > --------------040104090000090109080201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Barr,

Thanks for your comments. Please see my reply inline.

Barr Hibbs wrote:
I think this proposed option and set of sub-options is both unnecessary and
unlikely to be used.  I base my opinion on the existence of three current
DHCP options that are not, to my knowledge, used at all:

	option 72 -- Default World Wide Web (WWW) Server
	option 73 -- Default Finger Server
	option 74 -- Default Internet Relay Chat (IRC) Server

To be sure of my position, I configured two of the most widely used DHCP
servers with option 72 data, then released existing DHCP leases and rebooted
hosts using two different DHCP clients and two different web browsers,
monitoring the data exchange with Ethereal.  Neither client requested option
72 from the server and neither server sent the option without being
requested.  When the web browsers were started, neither one issued a
DHCPINFORM message requesting option 72.

Perhaps someone could come forward with a justification for these three
options?

Of course the DHC Working Group could define a means for configuring a
client with proxy server information, but I fear it would be like options
72, 73, and 74 -- unused.
I have explained the situation (in my earlier reply to  Robert Elz) where this proxy config option could be useful.
I do support that there are so many options like (72 to 74) which are not actively being used.
The key to success is to have DHCP client vendors as well as applications
vendors committed to using the option and sub-options if the DHC Working
Group were to define them.

I also object to this wording, found in section 4 of the draft:

   "More than one Sub Option MAY be specified for the same protocol.
   In that case, the precedence MUST be given in the order in which
   these options were received by the client. The first one received
   shall be given higher priority and so on."

I know of no other DHCP option in which the order of receipt mandates the
priority for use by the client, and I don't think this is a good precedent
to establish without a compelling reason to do so.  Consider the routers
(03) option:

   "The router option specifies a list of IP addresses for routers on the
   client's subnet.  Routers SHOULD be listed in order of preference."

There is only a recommendation ("SHOULD") that a client receiving this
option choose which router to use for subsequent IP messages according to
the order of appearance in the router option.  A client is free to choose
whichever router it wishes for future messages, possibly applying some other
information in making the choice.  I believe this is a very good model to
follow.
I agree that it shouldn't be MUST. Should be SHOULD. I didn't intend to write MUST here. It was my mistake
and my apologies for the confusion. Thanks a lot for the determinations.
"Security Considerations," section 8, contains this statement:

    "The DHCP Options defined here allow an unauthorized DHCP server to
    misdirect a client to access nonexistent/erring Proxy Server due to
    which the connection to the Internet might be denied."

Yes, but every other option presents an opportunity to misconfigure a
client, either unintentionally or maliciously.  The word "unauthorized"
implies that there is such a thing as an "authorized" DHCP server, which is
both incorrect and misleading.
I will update the doc with "interloper" DHCP server instead of  "unauthorized" DHCP server in section 8.
____________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--------------040104090000090109080201-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 17:06:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16474; Mon, 10 Nov 2003 17:06:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKAb-0008F6-OK; Mon, 10 Nov 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIytl-00076G-9m for dhcwg@optimus.ietf.org; Sun, 09 Nov 2003 18:23:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18616 for ; Sun, 9 Nov 2003 18:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyti-0001vC-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 18:23:10 -0500 Received: from bay4-f25.bay4.hotmail.com ([65.54.171.25] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AIyth-0001u0-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 18:23:09 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Nov 2003 15:22:40 -0800 Received: from 130.129.135.237 by by4fd.bay4.hotmail.msn.com with HTTP; Sun, 09 Nov 2003 23:22:39 GMT X-Originating-IP: [130.129.135.237] X-Originating-Email: [natpt@msn.com] From: "soohong park" To: gregk@redback.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Mon, 10 Nov 2003 08:22:39 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Nov 2003 23:22:40.0111 (UTC) FILETIME=[5E630FF0:01C3A718] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello Greg Sorry for my delaying >I'm afraid I'm not (yet) familiar with the IPv6 rapid reply mechanism >and I'm only slowly coming up to speed on some of DHC drafts that are >out there. IPv6 is rapid commit option and IPv4 is rapid reply option (temporary) >Could you please clarify what sort of environment needs this mechanism ? 1) For getting IP address and configuration information faster ! (especially in wireless environment) 2) Reducing the latency when performing address assignment. As Kostur said in previous mail, a Rapid Reply option would be handy, particularly in environments that may have a large number of devices attempting to Discover simultaneously. If failover is used, you have redundancy because there are multiple servers. And, Rapid Reply can be used with failover servers because they already have a facility to balance the load and decide which clients each server will respond to - hence, in failover mode a client won't be assigned two addresses (one by each server). So, with failover and Rapid Reply, you have fast address assignment (2 message exchange), no wasted addresses (a client is not assigned multiple addresses), and redundancy. I hope this is what you wanted clarification on. >In well set up dhcp environments the entire 4-message dhcp exchange can >be done in under 1 second, or at most a few seconds. Maybe the >environments you are working with do not have this behavior. 2-message exchange instead of 4-message. I think it can support for mobility as well. Regards Daniel (Soohong Daniel Park) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 17:06:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16475; Mon, 10 Nov 2003 17:06:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKAc-0008FH-8Y; Mon, 10 Nov 2003 17:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ6wO-00077T-El for dhcwg@optimus.ietf.org; Mon, 10 Nov 2003 02:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12082 for ; Mon, 10 Nov 2003 02:58:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ6wK-0000rF-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 02:58:24 -0500 Received: from mout0.freenet.de ([194.97.50.131]) by ietf-mx with esmtp (Exim 4.12) id 1AJ6wJ-0000rC-00 for dhcwg@ietf.org; Mon, 10 Nov 2003 02:58:23 -0500 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with asmtp (Exim 4.24) id 1AJ6wJ-0000Dq-SP for dhcwg@ietf.org; Mon, 10 Nov 2003 08:58:23 +0100 Received: from router.zeerio.net ([212.182.197.207] helo=thomas) by mx3.freenet.de with asmtp (ID thomas_gaebler@freenet.de) (Exim 4.24 #2) id 1AJ6wJ-0005U9-Gy for dhcwg@ietf.org; Mon, 10 Nov 2003 08:58:23 +0100 Message-ID: <001001c3a760$5c4942f0$6200a8c0@thomas> From: =?iso-8859-1?Q?Thomas_G=E4bler?= To: Date: Mon, 10 Nov 2003 09:57:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C3A771.1EF2D680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: [dhcwg] DHCP work like a hub Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C3A771.1EF2D680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have a problem,=20 =20 We have a DHCP-Server with 3 Interfaces, one for the internet with = static IP, the other ones for dhcp-clients. We want have one Subnet one = this two interfaces, how can we do that? For example, if I connect a pc on lan1, I get 192.168.1.10.=20 And later on lan2, if free the ip 192.168.1.10, that should possible = that I get this ip address. The two interfaces work like a hub. The = DHCP-Sever listen on two interfaces.=20 Thanks Thomas ------=_NextPart_000_000D_01C3A771.1EF2D680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We = have=20 a problem,=20

 

We=20 have a DHCP-Server with 3 Interfaces, one for the internet with static = IP, the=20 other ones for dhcp-clients.  We=20 want have one Subnet one this two interfaces, how can we do=20 that?

For=20 example, if I connect a pc on lan1, I get 192.168.1.10.=20

And later=20 on lan2, if free the ip 192.168.1.10, that should possible that I get = this ip=20 address. The two interfaces work like a hub. The DHCP-Sever listen on = two=20 interfaces.

 

Thanks

 

Thomas

------=_NextPart_000_000D_01C3A771.1EF2D680-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 10 18:05:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16473; Mon, 10 Nov 2003 17:06:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKAb-0008Ev-8v; Mon, 10 Nov 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyiI-00067L-U1 for dhcwg@optimus.ietf.org; Sun, 09 Nov 2003 18:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17741 for ; Sun, 9 Nov 2003 18:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyiF-0001iF-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 18:11:19 -0500 Received: from bay4-f39.bay4.hotmail.com ([65.54.171.39] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AIyiF-0001gj-00 for dhcwg@ietf.org; Sun, 09 Nov 2003 18:11:19 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Nov 2003 15:10:47 -0800 Received: from 130.129.135.237 by by4fd.bay4.hotmail.msn.com with HTTP; Sun, 09 Nov 2003 23:10:47 GMT X-Originating-IP: [130.129.135.237] X-Originating-Email: [natpt@msn.com] From: "soohong park" To: Andre@incognito.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Mon, 10 Nov 2003 08:10:47 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Nov 2003 23:10:47.0773 (UTC) FILETIME=[B5CCE8D0:01C3A716] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello Kostur No, I actually meant disabled. Recall that DHCP was designed to work in a scenario where there are multiple DHCP servers performing offers to clients. Rapid Commit/Reply is basically a feature where you tell the service that there isn't multiple DHCP servers (changing the default assumption in the protocol). ==> I definitely understand your mention, sorry for my misunderstanding. So... by default all DHCP servers will work properly in a multi-server environment unless it is explicitly told that it is the only server that will be answering (where "only" may include load-balanced and/or failover enabled pairs). ==>Exactly, I will consider it in the next draft Regards Daniel (Soohong Daniel Park) _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 11 03:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24404; Tue, 11 Nov 2003 03:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJUCs-0005RV-1V; Tue, 11 Nov 2003 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJUCh-0005RH-UV for dhcwg@optimus.ietf.org; Tue, 11 Nov 2003 03:48:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24388 for ; Tue, 11 Nov 2003 03:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJUCf-0007hR-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 03:48:49 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1AJUCe-0007hO-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 03:48:48 -0500 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 2690686; Tue, 11 Nov 2003 09:48:48 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Thomas =?iso-8859-1?q?G=E4bler?= , Subject: Re: [dhcwg] DHCP work like a hub Date: Tue, 11 Nov 2003 09:51:11 +0100 User-Agent: KMail/1.4.3 References: <001001c3a760$5c4942f0$6200a8c0@thomas> In-Reply-To: <001001c3a760$5c4942f0$6200a8c0@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200311110951.11130.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Monday 10 November 2003 08.57, Thomas G=E4bler wrote: > We have a DHCP-Server with 3 Interfaces, one for the internet with stat= ic > IP, the other ones for dhcp-clients. We want have one Subnet one this = two > interfaces, how can we do that? I think most DHCP servers should be able to do this as long as you A) lim= it=20 them to servicing the two inside interfaces (by pre-configuration) and B)= the=20 two inside interfaces are on the same logical subnet. If your two inside interfaces are not on the same subnet: our server has = a=20 setting that will allow it to give service with a "local" segment scope o= n a=20 non-matching local network, but you should be aware that, in this=20 configuration, lease renewals will have to be routed to the server. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 11 12:35:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12285; Tue, 11 Nov 2003 12:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcPu-0004ea-D2; Tue, 11 Nov 2003 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcPj-0004e1-I7 for dhcwg@optimus.ietf.org; Tue, 11 Nov 2003 12:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12269 for ; Tue, 11 Nov 2003 12:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcPh-0006nq-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 12:34:49 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJcPh-0006mb-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 12:34:49 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hABHYHmU016106 for ; Tue, 11 Nov 2003 09:34:17 -0800 (PST) Received: from mjs-xp.cisco.com (rtp-vpn2-324.cisco.com [10.82.241.68]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX06014; Tue, 11 Nov 2003 12:34:15 -0500 (EST) Message-Id: <4.3.2.7.2.20031111091114.01c6ab38@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Nov 2003 11:34:23 -0600 To: dhcwg From: Mark Stapp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] comments on draft-ietf-dhc-v4-threat-analysis-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I'd like to offer a few comments on the threat analysis draft. Thanks to the authors for initiating this discussion and review. Regards, Mark [1] scope - relay <-> server messages are included in the scope, but issues with those messages aren't discussed within the draft. in fact, section 4.4.2 could be read as excluding them from consideration. - the scope includes one-way authentication (server to client) as a special case, to permit clients to detect and ignore rogue servers. this case isn't discussed in the body of the document. [2] list of threats - what about forged or spurious RELEASE or DECLINE? we've seen DOS attacks that are intended to exhaust the servers' address pools using forged DECLINEs. - would it be useful to distinguish the categories a little differently? for example, there is a set of issues that are important in an enterprise network that's using 802.1x, another set of issues in a home net environment, another set in isp environments, and another set in public-access network 'hot-spots'. would talking about these concrete situations be helpful? [4.3] - not sure about the analogy to www clients. browsers don't ship with certs: they ship with a canned list of cert-signing authorities. and there's no authentication of the clients at any significant scale. the servers authenticate to the clients - if the clients bother to check CRLs. the dhcp clients would _each_ have to get a cert to use for some sort of cert-based rfc3118, and that's the barrier. they don't really need one for anything else, so asking that their admins generate one for each of them is probably asking too much. isn't it largely true that the authentication happens somewhere else - at the access point, using eap/leap/docsis ranging/etc ? I think this is something worth discussing in some depth. It's unlikely to be deployable to force every dhcp client to configure something extra just for dhcp. Is it in-scope to talk about revisions to rfc3118? section [3.4] implies that there are shortcomings in the design choice that was made to piggy-back auth on the existing message exchanges. For example, adding a couple of messages to allow for negotiation between client and server, or adding messages that could let the client and server go through a four-message exchange (carrying EAP, maybe?) might be worth considering. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 11 17:05:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23889; Tue, 11 Nov 2003 17:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgdC-0000zR-5f; Tue, 11 Nov 2003 17:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgR6-0000Oc-Fo for dhcwg@optimus.ietf.org; Tue, 11 Nov 2003 16:52:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23402 for ; Tue, 11 Nov 2003 16:52:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgR4-0002jv-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 16:52:30 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1AJgR3-0002jU-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 16:52:29 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hABLpin9747138; Tue, 11 Nov 2003 16:51:44 -0500 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hABLphst221926; Tue, 11 Nov 2003 16:51:43 -0500 In-Reply-To: <4.3.2.7.2.20031111091114.01c6ab38@goblet.cisco.com> Importance: Normal MIME-Version: 1.0 To: Mark Stapp Cc: dhcwg Subject: Re: [dhcwg] comments on draft-ietf-dhc-v4-threat-analysis-00.txt X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 Message-ID: From: Mimi Zohar Date: Tue, 11 Nov 2003 16:51:41 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5|September 18, 2003) at 11/11/2003 16:51:43, Serialize complete at 11/11/2003 16:51:43 Content-Type: multipart/alternative; boundary="=_alternative 0078176385256DDB_=" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0078176385256DDB_= Content-Type: text/plain; charset="US-ASCII" Mark, Thank you for taking the time to respond to the last call. My comments are prefixed with MZ>. Mimi [1] scope - relay <-> server messages are included in the scope, but issues with those messages aren't discussed within the draft. in fact, section 4.4.2 could be read as excluding them from consideration. MZ> Somehow during one of the rewrites, this discussion was removed from the document. As I recall, we excluded it since security of the relay <-> server messages, could be achieved through other means (e.g. IPSec). - the scope includes one-way authentication (server to client) as a special case, to permit clients to detect and ignore rogue servers. this case isn't discussed in the body of the document. MZ> Section 4 Security Requirements makes the case for needing authentication, which in section 4.2 Capabilities lists the four different options: no authentication, mutual authentication, client authentication, server authentication. [2] list of threats - what about forged or spurious RELEASE or DECLINE? we've seen DOS attacks that are intended to exhaust the servers' address pools using forged DECLINEs. MZ: Good point, will add. - would it be useful to distinguish the categories a little differently? for example, there is a set of issues that are important in an enterprise network that's using 802.1x, another set of issues in a home net environment, another set in isp environments, and another set in public-access network 'hot-spots'. would talking about these concrete situations be helpful? MZ: We tried a number of different ways, nothing really worked well. Bernard Aboba just suggested differentiating them by server/client issues. We haven't tried your suggestion. [4.3] - not sure about the analogy to www clients. browsers don't ship with certs: they ship with a canned list of cert-signing authorities. and there's no authentication of the clients at any significant scale. the servers authenticate to the clients - if the clients bother to check CRLs. the dhcp clients would _each_ have to get a cert to use for some sort of cert-based rfc3118, and that's the barrier. they don't really need one for anything else, so asking that their admins generate one for each of them is probably asking too much. MZ> I realize that presently it is uncommon for clients to have certificates; however, computers are today being shipped with TCPA chips, which perform public key cryptography without exposing the private key to the system. isn't it largely true that the authentication happens somewhere else - at the access point, using eap/leap/docsis ranging/etc ? I think this is something worth discussing in some depth. It's unlikely to be deployable to force every dhcp client to configure something extra just for dhcp. MZ> Agreed when you're speaking about wireless. I'm not familiar with docsis. Is it in-scope to talk about revisions to rfc3118? section [3.4] implies that there are shortcomings in the design choice that was made to piggy-back auth on the existing message exchanges. For example, adding a couple of messages to allow for negotiation between client and server, or adding messages that could let the client and server go through a four-message exchange (carrying EAP, maybe?) might be worth considering. MZ> I assume revisions to rf3118 is an option, but defer to someone else. --=_alternative 0078176385256DDB_= Content-Type: text/html; charset="US-ASCII"
Mark,

Thank you for taking the time to respond to the last call.   My comments are prefixed with MZ>.

Mimi


[1] scope
- relay <-> server messages are included in the scope, but issues
with those messages aren't discussed within the draft. in fact,
section 4.4.2 could be read as excluding them from consideration.

MZ> Somehow during one of the rewrites, this discussion was removed
from the document. As I recall, we excluded it since security of the
relay <-> server messages, could be achieved through other means
(e.g. IPSec).

- the scope includes one-way authentication (server to client) as
a special case, to permit clients to detect and ignore rogue
servers. this case isn't discussed in the body of the document.

MZ> Section 4 Security Requirements makes the case for needing
authentication, which in section 4.2 Capabilities lists the four
different options: no authentication, mutual authentication,
client authentication, server authentication.    

[2] list of threats
- what about forged or spurious RELEASE or DECLINE? we've seen DOS
attacks that are intended to exhaust the servers' address pools
using forged DECLINEs.
MZ: Good point, will add.

- would it be useful to distinguish the categories a little
differently? for example, there is a set of issues that are
important in an enterprise network that's using 802.1x, another
set of issues in a home net environment, another set in isp
environments, and another set in public-access network
'hot-spots'. would talking about these concrete situations be
helpful?

MZ:  We tried a number of different ways, nothing really worked well.
Bernard Aboba just suggested differentiating them by server/client issues.  
We haven't tried your suggestion.

[4.3]
- not sure about the analogy to www clients. browsers don't ship
with certs: they ship with a canned list of cert-signing
authorities. and there's no authentication of the clients at any
significant scale. the servers authenticate to the clients - if
the clients bother to check CRLs.

the dhcp clients would _each_ have to get a cert to use for some
sort of cert-based rfc3118, and that's the barrier. they don't
really need one for anything else, so asking that their admins
generate one for each of them is probably asking too much.

MZ> I realize that presently it is uncommon for clients to have
certificates; however, computers are today being shipped with TCPA
chips, which perform public key cryptography without exposing the
private key to the system.

isn't it largely true that the authentication happens somewhere else -
at the access point, using eap/leap/docsis ranging/etc ? I think this
is something worth discussing in some depth. It's unlikely to be
deployable to force every dhcp client to configure something extra
just for dhcp.
MZ> Agreed when you're speaking about wireless.  I'm not familiar with docsis.

Is it in-scope to talk about revisions to rfc3118? section [3.4]
implies that there are shortcomings in the design choice that was made
to piggy-back auth on the existing message exchanges. For example,
adding a couple of messages to allow for negotiation between client
and server, or adding messages that could let the client and server go
through a four-message exchange (carrying EAP, maybe?) might be worth
considering.
MZ> I assume revisions to rf3118 is an option, but defer to someone else.
--=_alternative 0078176385256DDB_=-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 11 18:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29196; Tue, 11 Nov 2003 18:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiGo-0001nW-5b; Tue, 11 Nov 2003 18:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiGh-0001n8-Vf for dhcwg@optimus.ietf.org; Tue, 11 Nov 2003 18:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29166 for ; Tue, 11 Nov 2003 18:49:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJiGe-0004fO-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 18:49:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJiGe-0004fL-00 for dhcwg@ietf.org; Tue, 11 Nov 2003 18:49:52 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 15:53:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABNnJDM013213 for ; Tue, 11 Nov 2003 18:49:20 -0500 (EST) Received: from mjs-xp.cisco.com (che-vpn-cluster-2-101.cisco.com [10.86.242.101]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX42418; Tue, 11 Nov 2003 18:49:17 -0500 (EST) Message-Id: <4.3.2.7.2.20031111174757.01c1e6a8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Nov 2003 17:48:50 -0600 To: dhcwg From: Mark Stapp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in particular. [2.1] Reachability Test Doesn't this sentence in 2.1 sort of turn DHCP on its head? "The purpose of the reachability test is to determine whether the host is connected to a network on which it had previously obtained a still valid routable IPv4 address." As I understand it, it's only the DHCP server who knows authoritatively whether the address binding that the client remembers is still valid. Working around that authority in circumstances where the server has failed, if the client could actually determine that, would be one thing. But working around that without the client's even attempting to confirm its binding with the server is problematic. This section states that a host may skip confirmation of its DHCP address when it reconnects under some circumstances. The DHCP INIT-REBOOT state is actually pretty important, and skipping it could have some undesireable consequences. As 2.1 is worded now, a host could have a week-old memory of an address it got on network A, and could re-use it upon reconnecting to network A without attempting INIT-REBOOT. That's a pretty dramatic change, if I've read the text accurately, and I'm not comfortable with it. Is the goal of 2.1 to assist clients who have marginal connections - wireless clients whose associations are flapping, for example? Maybe a time-based, stateful heuristic would be appropriate here. For example, if the host believes that it has reconnected to network A, and that it last communicated with the DHCP server on network A within the last - one minute? five minutes? - then it could proceed without INIT-REBOOT. If the host had a) been off of network A for more than five minutes, or b) been attached to some other network since it last attached to network A then it would go through INIT-REBOOT normally. Or are there folks who think that the client should always do INIT-REBOOT if it can? In that case, if there's a latency issue for some types of client or some types of link, maybe we should try to make a low-latency answer available from the server without changing the client behavior at all. Thanks, Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 12 00:44:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09304; Wed, 12 Nov 2003 00:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnnN-0001cN-DC; Wed, 12 Nov 2003 00:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnmq-0001SP-IY for dhcwg@optimus.ietf.org; Wed, 12 Nov 2003 00:43:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09251 for ; Wed, 12 Nov 2003 00:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnmn-0001FQ-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 00:43:25 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AJnmn-0001FM-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 00:43:25 -0500 Received: from [130.129.135.172] (dyn135-172.ietf58.ietf.org [130.129.135.172]) by toccata.fugue.com (Postfix) with ESMTP id F2AFC1B29F1; Tue, 11 Nov 2003 23:36:10 -0600 (CST) In-Reply-To: <4.3.2.7.2.20031111174757.01c1e6a8@goblet.cisco.com> References: <4.3.2.7.2.20031111174757.01c1e6a8@goblet.cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21CBCCC2-14D3-11D8-879F-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg From: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt Date: Tue, 11 Nov 2003 23:43:24 -0600 To: Mark Stapp X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some people have made a lot of what I would consider a misreading of RFC2131 - that INIT-REBOOT is optional. I believe it's optional because some hosts may not have stable store, not because hosts that *do* have stable store should ever skip INIT-REBOOT. I think that in order to get good behavior in the case where we have flapping going on on an 802.11 link, it's going to require a compromise on one of three directions. The choices are (remember, this is just for 802.11): - Try to do it right. This means that when we see a change, we look for a new configuration but don't immediately throw out the old, in the sense that we keep the old address configured alongside the new, and only kill it off after a timeout has passed. I don't think that anybody is going to implement this, and I'm not seriously proposing it - just wanted to mention it. - Compromise in the direction of switching quickly. This means that when we detect a possible change in attachment, we assume that the old connection is gone and never coming back. So we throw it away immediately and switch. MacOS X does this now. My wife Andrea was unable to get her email for quite a while this afternoon as a result, because she has a Titanium, which has, shall we say, antenna issues. She kept losing her access point in the middle of downloading her email, so she got the same ten messages quite a few times before she gave up. - Compromise in the direction of switching slowly. AFAIK nobody does this now. What this means is that when we notice a network transition, we keep it in mind, but don't try to reconfigure immediately - we wait 90 seconds, long enough for any active TCP sessions to time out. If, during that timeout period, the old network comes back, we continue using it. After this period has passed, we give up and move to the new network. This is a point solution for 802.11. I think that aggressive switching probably works fine for ethernet and similar media, because a change in media is usually a physical process. The solutions proposed in DNAv4 having to do with not trying to reconfigure until we actually detect a new link, as opposed to the loss of the old link, make a lot of sense - this means that if the switch is power cycled, we don't lose our address, but if we're plugged into a different switch, we get a new address quickly. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 12 11:14:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24774; Wed, 12 Nov 2003 11:14:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxd3-0003jx-Sw; Wed, 12 Nov 2003 11:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxcs-0003is-1I for dhcwg@optimus.ietf.org; Wed, 12 Nov 2003 11:13:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24736 for ; Wed, 12 Nov 2003 11:13:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxcr-0001Jg-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 11:13:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AJxcq-0001JC-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 11:13:48 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACGDEDM004264; Wed, 12 Nov 2003 11:13:15 -0500 (EST) Received: from mjs-xp.cisco.com (che-vpn-cluster-2-74.cisco.com [10.86.242.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX80252; Wed, 12 Nov 2003 11:13:12 -0500 (EST) Message-Id: <4.3.2.7.2.20031112085245.02397650@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Nov 2003 10:13:00 -0600 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt Cc: dhcwg In-Reply-To: <21CBCCC2-14D3-11D8-879F-000A95D9C74C@fugue.com> References: <4.3.2.7.2.20031111174757.01c1e6a8@goblet.cisco.com> <4.3.2.7.2.20031111174757.01c1e6a8@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ted, Couldn't quite tell from this whether you agreed with me that the text in the draft was ... too general. Like your wife, I've occasionally had 802.11 troubles, and I'd be interested in providing some guidelines that would make it easier for an 802.11 client to deal with those troubles better. I don't read INIT-REBOOT to mean 'throw out your configuration.' I've read it as 'try to confirm that your configuration is still valid'; there are lots of ways of optimizing the confirmation process. The dna draft proposes optimizing it by avoiding it - skipping the confirmation message based on some heuristic. The heuristic that's in the text isn't restricted to 802.11 clients, and isn't time-based or damped. The draft also doesn't discuss interactions between L2 (which notices that the link has gone down and been reconnected), the IP stack, and the DHCP client, and I agree with you that users are most likely to notice a transient link problem if it takes down their TCP connections. I'd like to distinguish 'reconfiguration' from 'confirmation'. I agree that helping 802.11 clients avoid unnecessary reconfiguration is desirable, and I'd support text that made specific recommendations for those clients. But the -04 draft loses the benefits of confirmation in too many situations. -- Mark At 11:43 PM 11/11/2003 -0600, Ted Lemon wrote: >Some people have made a lot of what I would consider a misreading of >RFC2131 - that INIT-REBOOT is optional. I believe it's optional because >some hosts may not have stable store, not because hosts that *do* have >stable store should ever skip INIT-REBOOT. > >I think that in order to get good behavior in the case where we have >flapping going on on an 802.11 link, it's going to require a compromise on >one of three directions. The choices are (remember, this is just for 802.11): > >- Try to do it right. This means that when we see a change, we look for >a new configuration but don't immediately throw out the old, in the sense >that we keep the old address configured alongside the new, and only kill >it off after a timeout has passed. I don't think that anybody is going >to implement this, and I'm not seriously proposing it - just wanted to >mention it. >- Compromise in the direction of switching quickly. This means that when >we detect a possible change in attachment, we assume that the old >connection is gone and never coming back. So we throw it away >immediately and switch. MacOS X does this now. My wife Andrea was >unable to get her email for quite a while this afternoon as a result, >because she has a Titanium, which has, shall we say, antenna issues. >She kept losing her access point in the middle of downloading her email, >so she got the same ten messages quite a few times before she gave up. >- Compromise in the direction of switching slowly. AFAIK nobody does this >now. What this means is that when we notice a network transition, we >keep it in mind, but don't try to reconfigure immediately - we wait 90 >seconds, long enough for any active TCP sessions to time out. If, during >that timeout period, the old network comes back, we continue using >it. After this period has passed, we give up and move to the new network. > >This is a point solution for 802.11. I think that aggressive switching >probably works fine for ethernet and similar media, because a change in >media is usually a physical process. The solutions proposed in DNAv4 >having to do with not trying to reconfigure until we actually detect a new >link, as opposed to the loss of the old link, make a lot of sense - this >means that if the switch is power cycled, we don't lose our address, but >if we're plugged into a different switch, we get a new address quickly. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 12 12:40:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29216; Wed, 12 Nov 2003 12:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyyH-0003SP-Sr; Wed, 12 Nov 2003 12:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyy0-0003Rp-8L for dhcwg@optimus.ietf.org; Wed, 12 Nov 2003 12:39:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29207 for ; Wed, 12 Nov 2003 12:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyxy-0002wM-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 12:39:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJyxy-0002wH-00 for dhcwg@ietf.org; Wed, 12 Nov 2003 12:39:42 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 09:39:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hACHd7mW017597 for ; Wed, 12 Nov 2003 09:39:10 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-43.cisco.com [10.82.240.43]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX90006; Wed, 12 Nov 2003 12:39:06 -0500 (EST) Message-Id: <4.3.2.7.2.20031112123834.028e1b90@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Nov 2003 12:39:03 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] dhc WG meeting agenda (revised) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG agenda - IETF 58 Thu 11/13/2003 0900 (Last revised 11/12/2003 12:36 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing Current last calls: failover; DHCPv4 threat analysis; PXE options Node-Specific Client Identifiers for DHCPv4 Ted Lemon 10 minutes Initial discussion Rapid Reply Option for DHCPv4 S. D. Park 10 minutes Accept as WG work item? Client Identifier option in server replies Ralph Droms 10 minutes Accept as WG work item? Extending DHCP Options Codes Ralph Droms 10 minutes Discussion; which extension plan to accept; next steps/roadmap Implementation Issues with RFC 2131 Ralph Droms 20 minutes Discussion; next steps; other work related to advancing RFC 2131 DHCPv4 Threat Analysis Mimi Zohar (?) 10 minutes Final discussion; solicit WG last call review DHCP Authentication using DNS KEY records Ted Lemon 10 minutes Flexible Authentication for DHCP Messages Mimi Zohar (?) 10 minutes Discussion of DHCP authentication Ralph Droms 20 minutes Review three authentication proposals; next steps/roadmap Configuration of dual-stack hosts with DHCP Ralph Droms 20 minutes ----------- Total 135 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 08:36:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25711; Thu, 13 Nov 2003 08:36:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHdg-0001Vb-Vq; Thu, 13 Nov 2003 08:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHdM-0001Us-9N for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 08:35:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25603; Thu, 13 Nov 2003 08:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHdK-0004lC-00; Thu, 13 Nov 2003 08:35:38 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AKHdK-0004kf-00; Thu, 13 Nov 2003 08:35:38 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2003 05:35:08 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hADDZ4rX005039; Thu, 13 Nov 2003 05:35:04 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-545.cisco.com [10.82.226.33]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADY52712; Thu, 13 Nov 2003 08:35:02 -0500 (EST) Message-Id: <4.3.2.7.2.20031113074713.01e59b18@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 07:57:34 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Cc: iesg@ietf.org, dhcwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Pekka - thanks for your review. My responses to your comments are inline. - Ralph At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote: >On Thu, 30 Oct 2003, The IESG wrote: > > The IESG has received a request from the Dynamic Host Configuration WG to > > consider the following document: > > > > - 'A Guide to Implementing Stateless DHCPv6 Service' > > as a Proposed Standard > >Comments below. The document needs a revision, but does not have, AFAICS, >major issues to deal with, except for better considerations on how DHCP >relays work (or don't :-) in the stateless/full DHCP model.. that is, do >you have "stateless relays" and "full relays", and potential problems to >stateful services stemming from that or not. > >Note: IMHO, DHCP spec should have been the other way around, stateless >first, adding stateful parts on top of that as an extension. Can't be >changed now, but might be something to consider when going to Draft >Standard or the like. > >substantial >----------- > >1) the spec is not sufficiently clear how the relays behave in a mixed world >of stateless/stateful DHCP service. That is, would deploying a >stateless-only relay (if such a thing is possible?) harm the stateful DHCP >clients? Is the implementation of a relay any different for full/stateless >DHCP service, etc. ?: > > The operation of relay agents is the same for stateless and stateful > DHCPv6 service. The operation of relay agents is described in the > DHCPv6 specification. The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are all completely defined in RFC 3315. From the point of view of the DHCPv6 relay agent, there is no difference between the subset of RFC 3315 referred to as "stateless DHCPv6" and the full set of functions in RFC 3315. More concisely, there are just "DHCPv6 relay agents" that work with both full RFC 3315 clients and stateless-only clients... >2) there are a few remnants on the spec which talk about "DNS configuration >parameters". One should be more generic than that; these are listed in the >editorials section. OK... >3) I'm not familiar with DHCPv6 spec, but I'd like a confirmation that the >last sentence is actually true, and to reword it for clarity if so: > > A DHCP server that is only able to provide stateless configuration > information through an Information-request/Reply message exchange > discards any other DHCP messages it receives. Specifically, the > server discards any messages other than Information-Request or > Relay-forward it receives, and the server does not participate in any > stateful address configuration messages exchanges. If there are > other DHCP servers that are configured to provide stateful address > assignment, one of those servers will provide the address assignment. > >==> that is, do relays really *flood* these messages to all the DHCPv6 >servers they know, so that if one doesn't process the request but silently >ignores it, the others can step up and handle the job? See also the point >1) above. Yes, a relay agent forwards a copy of each message it receives from a client to each of the servers in its configured list of servers. >editorial >--------- > > the node's message with a Reply message that carries the DNS > configuration parameters. The Reply message from the server can > >==> s/DNS// OK. > 1-4: give an introduction to DHCPv6 and an overview of DHCP message > flows > >==> some of those flows are redundant to Stateless DHCPv6 operation, >though.. :-) OK, would a more precise list (e.g., individual subsections rather than simply "1-4") be helpful? >5. Implementation of stateless DHCP > > >==> s/stateless/Stateless/ OK. > DNS configuration information, it includes either or both of the DNS > configuration options in the Information-request message. > >==> one should list here the two kinds of DNS config options, or reword the >sentence. OK. >5.1 Messages required for stateless DHCP > > >==> s/r/R/, s/s/S/ OK. > Clients and servers implement the following messages for stateless > DHCP service; the section numbers in this list refer to the DHCPv6 > specification: > >==> many sections are missing the "the section ..." blurb. It might make >sense to add something at the end of section 5, like, "In the following >subsections, the section numbers used refer to the DHCPv6 specification". > > Information-request: sent by a DHCP client to a server to request DNS > configuration parameters (sections 18.1.5 and 18.2.5) > > > Reply: sent by a DHCP server to a client containing the > DNS configuration parameters (sections 18.2.6 and 18.2.8) > >==> s/DNS// (2 cases) OK. >5.2 Options required for stateless DHCP service > > >==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other >5.x) OK >5.3 Options used for configuration information > > >==> s/u/U/, s/c/C/, s/i/I/ OK >5.4 Other options used in stateless DHCP > > >==> s/o/O/, s/u/U/, s/s/S/ OK (more precisely, I'll make sure the capitalization is consistent in section headers throughout) > DHCP service; the section numbers in this list refer to the DHCPv6 > specification, RFC 3315>: > >==> see above, but if keeping it here, make consistent with the rest OK > 22.2). Clients are not required to send this option; servers send > the option back if included in a message fro ma client > > >==> s/fro ma/from a/ OK >-- >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 10:00:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29878; Thu, 13 Nov 2003 10:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIx4-00083J-0v; Thu, 13 Nov 2003 10:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIw4-0007ip-KS for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 09:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29660 for ; Thu, 13 Nov 2003 09:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIvx-0006D7-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 09:58:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AKIvx-0006Cq-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 09:58:57 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hADEwNw5022307 for ; Thu, 13 Nov 2003 06:58:24 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-400.cisco.com [10.82.241.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADY58566; Thu, 13 Nov 2003 09:58:22 -0500 (EST) Message-Id: <4.3.2.7.2.20031113095802.026bdc80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 09:58:17 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Revised agenda Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG agenda - IETF 58 Thu 11/13/2003 0900 (Last revised 11/13/2003 09:55 AM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing Current last calls: failover; DHCPv4 threat analysis; PXE options New I-Ds to be considered by the dhc WG Ralph Droms 15 minutes Node-Specific Client Identifiers for DHCPv4 Ted Lemon 10 minutes Initial discussion Rapid Reply Option for DHCPv4 S. D. Park 10 minutes Accept as WG work item? Vendor-Identifying Vendor Options for DHCPv4 Ralph Droms 05 minutes Client Identifier option in server replies Ralph Droms 10 minutes Accept as WG work item? Extending DHCP Options Codes Ralph Droms 10 minutes Discussion; which extension plan to accept; next steps/roadmap Implementation Issues with RFC 2131 Ralph Droms 20 minutes Discussion; next steps; other work related to advancing RFC 2131 DHCPv4 Threat Analysis Mimi Zohar 10 minutes Final discussion; solicit WG last call review Platform integrity measurements Mimi Zohar 05 minutes Discussion of DHCP authentication Ralph Droms 20 minutes Review three authentication proposals; next steps/roadmap Configuration of dual-stack hosts with DHCP Ralph Droms 20 minutes ----------- Total 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 10:04:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00293; Thu, 13 Nov 2003 10:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ0r-0000Bq-FT; Thu, 13 Nov 2003 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ0o-0000BX-1w for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 10:03:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00211 for ; Thu, 13 Nov 2003 10:03:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ0l-0006On-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:03:55 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AKJ0k-0006Nn-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:03:54 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119089>; Thu, 13 Nov 2003 15:55:12 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 13 Nov 2003 16:02:58 +0100 Message-ID: From: "Rentschler, Markus" To: "Kostur, Andre" , dhcwg@ietf.org Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions Date: Thu, 13 Nov 2003 16:02:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ---------------------------------------------------------------- Thus by default, any device on the network would be able to trigger a DDoS attack on your DHCP infrastructure by sending a broadcast DHCPNETSCAN (again, we're talking about the proposed _default_ configuration)? [MR>] This security hole is indeed the most painful aspect of the Discovery Extensions. Besides the proposed bandwith limitation, a possible solution could be: DHCP is at startup by default issuing DHCPDISCOVER. As long as the device has no lease, broadcasted DHCPNETSCANs must not be answered. After the device got its lease, only DHCPNETSCANs from the lease-granting server will be answered OR only after some authentication took place (authentication mechanism would have to be developed). But this would eliminate one of the advantages of the Discovery extensions: No flooding mit DHCPDISCOVER messages at boot time and configuration under complete control of the server. What is your recommendation for the default settings from your point of view ? So far the default settings where not that important to me. In our environments (very restricted access and a maximum of a few thousand devices) I would just enable everything and be quite save as long as the Admin doesn't make nonsense himself. Maybe one should explicitly restrict the Discovery Extensions to such types of networks? ---------------------------------------------------------------- In which case, why doesn't the admin simply enable DHCP to begin with. This would make DHCPCONFIGURE redundant (the device will already have a lease, or will DISCOVER soon. And accept FORCERENEW (assuming RFC 3203 is implemented) ). [MR>] I considered using the FORCERENEW instead of DHCPCONFIGURE in the beginning. I came up to dislike the FORCERENEW mechanism for the following reasons: It operates that way: The server who wants to initiate reconfiguration tells the client to ask at the same server for a new configuration! A little bit complicated, isn't it ? Especially for the server implementation when it wants so supervise the whole reconfiguration process! The FORCERENEW mechanism leads to a seven (!) message exchange for the reconfiguration of a single(!) client ! FORCERENEW -> DHCPREQUEST -> DHCPNAK -> DHCPDISCOVER -> DHCPOFFER -> DHCPREQUEST -> DHCPACK That produces a lot of superfluous network traffic. The straightforward way would be that the server tells the client it's new configuration and gets an ACK to be sure everything went ok. That's the way the DHCPCONFIGURE/DHCPREPORT mechanism works which even provides additional flexibility besides that. And what happens when the server crashed and all the lease info is lost ? No possibility to get any information about clients with FORCERENEW With DHCPNETSCAN one could easily recover the leae database without the need to boot up all the clients (which would be inacceptable anyway). ---------------------------------------------------------------- The draft still has additional state transitions to document. For example: upon receiving a DHCPNETSCAN in the BOUND state, the client must transmit a DHCPREPORT and transition back to the BOUND state. Upon receiving a DHCPNETSCAN in the INIT-REBOOT state, do what? How about SELECTING? The draft is proposing 3 new messages. The draft needs to document what is going to happen in _every_ state of the DHCP client state machine when it receives any of the 3 messages (OK, 2 messages, clients shouldn't be getting REPORTs). [MR>] OK, a state diagram with the extensions can be drawn. I thought this was unnecessary since the behaviour of the Discovery Extensions is so simple, that IMHO a textual description is far better understandable than a state diagram made of ASCII characters. ---------------------------------------------------------------- > > Another thought... what happens if the device sends the > RELEASE, then > > sends the REPORT, but the REPORT is lost? (keep in mind > that this is all > > UDP... UDP packets may get dropped). > > > [MR>] Then the server will have to retransmit its DHCPCONFIGURE > until it gets a DHCPREPORT from that device. > Since this is done on layer 2, it is not important if the device > accepted the initial DHCPCONFIGURE or still uses it's old or > no ip address at all. However, in the meantime there's a DHCP device out there that has an IP address, which the DHCP server has no valid lease for. This opens up the possibility of duplicate IP address allocation. [MR>] I don't agree on that. The first IP that was RELEASEed is not longer in use, since the device accepted the new ip setting. The server has no valid lease on that new ip setting, but it knows that the REPORT is outstanding and must of course not give that ip address to another client until its recovery mechanism timed out. And additionally there is still the mechanism that DHCP should check via an ARP request if an IP address is already in use. ---------------------------------------------------------------- > > > [MR>] > > > Both should be possible: configuration AND reconfiguration, > > We already have a mechanism for reconfiguration. Why > reinvent the wheel, > > which only adds additional overhead? > > > [MR>] Sure, but there is no mechanism for server-originated > CONfiguration. That's what the draft is all about. If the device is configured to use DHCP anyway, you only need to wait until the device performs a DISCOVER. [MR>] What about the scenario that Lease Duration is infinite, the Server has crashed and lost its lease information ? Or an additional server is plugged onto a running network ? Or a network is going to be reorganized/reconfigured/altered without booting all clients ? ---------------------------------------------------------------- > > one mildly malicious user can emit a NETSCAN once an hour and cause your > > entire network of 200000 devices to DDoS your real DHCP server by > > hammering it with 200000 REPORTs, > > > [MR>] That is the only point that makes me some headache too. > I would like to get some ideas how this potential > danger could be minimised. > With normal DHCP we got a similar Problem at bootup, when every > client emits it DHCPDISCOVER messages. Granted, if your entire network is rebooting, the servers will undergo a severe load. However this would (hopefully) be a fairly rare event. With this proposed draft, it even suggests initiating this load on a periodic basis! [MR>] I see there no real difference to what a management software does that is periodically PINGing its network to check if all agents are still responding. ---------------------------------------------------------------- > > > > OK, what happens in the case: > > > > 1) Device A sends the RELEASE > > > > 2) Device B Discovers & Requests (since the IP is now > > > available, it was > > > > just released!) the now released IP > > > > 3) Device A REPORTs on that IP ? > > > [MR>] > > > The REPORT must of course use the new IP assigned with > > > DHCPCONFIGURE, since it is the REPORT's main job to tell the > > > rest of the network that a certain client has a certain > configuration. > > > So there should be no problem. > > There's a big problem. There is now two devices with the > same IP address. > > > > > [MR>] > How do you get that idea ?? > Device A has released the IP, since it got a DHCPCONFIGURE > with new settings AND accepted them (Otherwise there would be no > RELEASE). > So only Device B has this IP. Not necessarily true. Device A gets a DHCPCONFIGURE to change it's DNS settings. Since Device A has a current lease, the draft says that it needs to DHCPRELEASE it first. Now the DHCP server has released the IP, but the client is still using the IP. Device B comes and does a DISCOVER/REQUEST, receiving that IP. Presto, duplicate IP. [MR>] Well, how long does Device A still have the old ip after DHCPRELEASE ? 0.001 seconds ?-) The next operation in the code would of course be setting up the ip stack with the new parameters. ---------------------------------------------------------------- > > Then it is a different protocol, and should be treated as such. > > > [MR>] It does the same (configuring the client with ip and some other parameters), > just in a slightly different way that offers some additional opportunities for network administrators. So far, I don't see the advantage of using this particular scheme over the already specified RFC 3203. I think that 3203 has some elegance in it that it reuses as much of the existing DHCP infrastructure as possible. [MR>] I agree that RFC 3203 has some elegance in terms of simple incorporation into the DHCP client. I think it was designed on this premise: As much client-initiated behaviour as possible, even when the intention is doing server-initiated reconfiguration. That's the reason why in the end we come up with a seven message exchange for a simple reconfiguration that could be done with two messages. ---------------------------------------------------------------- Instead of the FORCERENEW attempting to do everything, it only triggers the client to renew immediately, instead of waiting for the full lease time. [MR>] RFC 3203 is an elegant solution for exactly that purpose, but beyond that IMHO it reaches it's limitations very quickly. ---------------------------------------------------------------- Results in the client doing a unicast RENEW, which if all you're changing is the DNS settings, the client could easily only change the DNS settings resulting in as little disruption to IP services as possible (client implementation detail...). And if you're chaging the IP settings, the device would get a normal NAK to the request, causing the client to perform all the normal DHCP behaviours associated with the NAK. [MR>] Sure, this mechanism works and is very easy to implement on clients, but on what costs ? Lots of messages get exchanged and the server has to incorporate a very complicated state machine to supervise the reconfiguration process. Do you know of any publicly available servers that support RFC 3203 ? ---------------------------------------------------------------- This draft seems to imply that a device _must_ have a DHCP state machine running, even if the device isn't going to be using DHCP. [MR] In this case the device IS going to use DHCP (Discovery Extensions), but not sending initial DHCPDISCOVER messages. This is simply to avoid flooding the network at boot time mit DHCPDISCOVER messages and doing the configuration under the control of the Server. If the device is already using DHCP, then this draft is redundant with other, already specified behaviours (Failover, RFC 3203, RFC 2131) (Again, if the device is already using DHCP, it will DISCOVER on it's own, or it will have an established lease). [MR>] Again, my scenario with the crashed server and the device/topology detection possibility. This is only solveable with the Discovery mechanism (DHCPNETSCAN/DHCPREPORT). The combination DHCPCONFIGURE/DHCPREPORT is IMHO a much better solution to the server-initiated configuration problem than the RFC 3203 mechanism that is IMHO more or less a workaround to the dogma of traditional DHCP that the client must initate communication. The redundancy mechanism is an additional goodie that the discovery mechanism COULD provide. And I can think of a variety of other useful applications of the Discovery Extensions, I just dont't want to name them here for not feeding potential competitors too much. I regard the Discovery Protocol as a powerful thing that offers a lot of potential applications. And since it performs the same task than DHCP (Dynamic Host Configuration), it is IMHO in the right place as a configurable extension to DHCP , especially since the DHCP packet format and infratructure (relay agents) can be used for implementation with very little effort. Im aware of it's cons (DDoS through DHCPNETSCAN) and recommend that it should only be used in environments where such an attack is unlikely to occur (networks with restricted access). Regards, Markus _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 10:48:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04076; Thu, 13 Nov 2003 10:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJhQ-0005xT-OE; Thu, 13 Nov 2003 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJgk-0005vu-My for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 10:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03983 for ; Thu, 13 Nov 2003 10:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJgi-0007LB-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:47:16 -0500 Received: from mail.tgm.ac.at ([193.170.8.132]) by ietf-mx with esmtp (Exim 4.12) id 1AKJgh-0007KD-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:47:15 -0500 Received: from localhost (mail [127.0.0.1]) by mail.tgm.ac.at (Postfix) with ESMTP id C13AB71C60 for ; Thu, 13 Nov 2003 16:46:42 +0100 (CET) Received: from mail ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 09197-08 for ; Thu, 13 Nov 2003 16:46:42 +0100 (CET) Received: from mail.tgm.ac.at (mail [127.0.0.1]) by mail (AvMailGate-2.0.1.6) id 09565-07C28D57; Thu, 13 Nov 2003 16:46:42 +0100 Received: from tgm.ac.at (unknown [10.3.4.214]) by mail.tgm.ac.at (Postfix) with ESMTP id 6D2532438B for ; Thu, 13 Nov 2003 16:46:42 +0100 (CET) Message-ID: <3FB3A761.9030803@tgm.ac.at> Date: Thu, 13 Nov 2003 16:46:41 +0100 From: Markus Schabel Organization: TGM User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2 X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.22.0.1; VDF: 6.22.0.36; host: tgm.ac.at) Content-Transfer-Encoding: 7bit Subject: [dhcwg] LDAP Schema for DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello! I'd like to store active DHCP leases in my LDAP directory. Since I didn't like to re-invent the wheel I found the following draft: http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-dhc-ldap-schema-00.txt As you can see it's quite old. Is there a newer version available somewhere? And if not, are there any plans to release a newer version or is the whole concept of storing DHCP information in LDAP put away, and if this is so, why? best regards Markus Schabel _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 10:58:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04528; Thu, 13 Nov 2003 10:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJr6-0006Xs-St; Thu, 13 Nov 2003 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJqm-0006XL-0i for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 10:57:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04495 for ; Thu, 13 Nov 2003 10:57:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJqj-0007Vc-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:57:37 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AKJqi-0007VZ-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 10:57:36 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hADFvRAr060616; Thu, 13 Nov 2003 10:57:36 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Markus Schabel'" , Subject: RE: [dhcwg] LDAP Schema for DHCP Date: Thu, 13 Nov 2003 10:57:35 -0500 Message-ID: <000501c3a9fe$de985b60$6401a8c0@BVolz> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FB3A761.9030803@tgm.ac.at> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable There was some work done a while ago on this topic but it never was = finished and there has generally been a lack of interest to do it (at least in a standardized way). One issue is that servers have very different capabilities and therefore developing a standard limits functionality to = the "common" capabilities. There are some servers that do use LDAP or can = store information in LDAP, but I think they've generally used a proprietary schema. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Markus Schabel Sent: Thursday, November 13, 2003 10:47 AM To: dhcwg@ietf.org Subject: [dhcwg] LDAP Schema for DHCP Hello! I'd like to store active DHCP leases in my LDAP directory. Since I didn't like to re-invent the wheel I found the following draft: http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-dhc-ldap-schema-00.t= xt As you can see it's quite old. Is there a newer version available somewhere? And if not, are there any plans to release a newer version or is the whole concept of storing DHCP information in LDAP put away, and if this is so, why? best regards Markus Schabel _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 14:13:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13423; Thu, 13 Nov 2003 14:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMto-0005Bj-Qh; Thu, 13 Nov 2003 14:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMsv-0005AC-Ll for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 14:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13352 for ; Thu, 13 Nov 2003 14:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMst-00035B-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 14:12:03 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMsn-000355-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 14:12:02 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA20867; Thu, 13 Nov 2003 19:11:50 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA19404; Thu, 13 Nov 2003 19:11:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hADJBjO05264; Thu, 13 Nov 2003 19:11:45 GMT Date: Thu, 13 Nov 2003 19:11:45 +0000 From: Tim Chown To: dnsop@cafax.se, dhcwg@ietf.org Message-ID: <20031113191145.GS3473@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I was mulling over the renumbering scenario for hosts that use stateless autoconf for address allocation and DHCPv6 Light (stateless DHCPv6) for DNS options. Let's assume either the site renumbers, or the DNS servers are renumbered. The latter case means that you can't just use a new prefix on an RA as a hint to re-request DNS options via DHCPv6 Light. With an RA method for DNS option configuration, you put the new DNS option information in the RA. With DHCPv6 Light for DNS option configuration, how is the client told that DNS options have changed? The reconfigure message seems to be unicast to the clients, but if the DHCPv6 server is stateless, it won't have a list of clients (with leased IPs) to send that Reconfigure message to? Is this a general problem for any options set by a host that only uses stateless DHCPv6 for options, and use RFC2462 for addresses. One option for passing the new DNS options from the DHCPv6 Light server to the client is a multicast Reconfigure message. That would work if the DHCPv6 Light server is on link, but if relays are used and there is no multicast routing on site, this seems to be a gap (and a case for the RA method - though of course with RA method you still need to reconfigure the router for the new RA...) Thoughts? Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 15:13:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17390; Thu, 13 Nov 2003 15:13:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNpr-000213-OZ; Thu, 13 Nov 2003 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNpY-0001zb-Up for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 15:12:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17306 for ; Thu, 13 Nov 2003 15:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNpX-0004EZ-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:12:39 -0500 Received: from gura.nttv6.jp ([210.163.36.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKNpX-0004EL-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:12:39 -0500 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 4C0CD1FE47; Fri, 14 Nov 2003 05:12:07 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 5E52D125FBD; Fri, 14 Nov 2003 05:12:06 +0900 (JST) Date: Fri, 14 Nov 2003 05:12:05 +0900 (JST) Message-Id: <20031114.051205.48455194.yasuhiro@nttv6.jp> To: tjc@ecs.soton.ac.uk Cc: dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? From: SHIRASAKI Yasuhiro In-Reply-To: <20031113191145.GS3473@login.ecs.soton.ac.uk> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 13 Nov 2003 19:11:45 +0000, Tim Chown wrote: > One option for passing the new DNS options from the DHCPv6 Light server > to the client is a multicast Reconfigure message. That would work > if the DHCPv6 Light server is on link, but if relays are used and there > is no multicast routing on site, this seems to be a gap (and a case for the > RA method - though of course with RA method you still need to reconfigure > the router for the new RA...) Both setting the trigger of re-request on renumbering of prefix in RA, and a multicast Reconfigure message might cause all nodes to rush on the single DHCPv6-lite server for information-request reply exchange. It could work with small number of clients though. Periodical information-request from client side as Ralph suggested, and multicast advertisement of DNS option itself (w/ DHCPv6-lite, RA, SLP) seems to work with large number of clients. -- SHIRASAKI Yasuhiro _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 15:17:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17904; Thu, 13 Nov 2003 15:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNtk-0002eW-Qr; Thu, 13 Nov 2003 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNtR-0002eE-Sy for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 15:16:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17795 for ; Thu, 13 Nov 2003 15:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNtQ-0004L0-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:16:40 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AKNtP-0004Kx-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:16:40 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 299AC1C00CCD; Thu, 13 Nov 2003 15:16:37 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id BAA20377; Fri, 14 Nov 2003 01:45:21 +0530 (IST) Message-ID: <3FB3E69E.4060705@india.hp.com> Date: Fri, 14 Nov 2003 01:46:30 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown Cc: dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> In-Reply-To: <20031113191145.GS3473@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess, "stateless" means the server doesn't need to maintain the lifetime of the configuration information it has assigned to the clients and it doesn't mean that it doesn't need to maintain the information about the clients.. The proposal of sending multicast reconfigure message was discussed, but it was dropped as its very difficult to achieve multicast security and reconfigure mechanism mandates auth... Vijay Tim Chown wrote: >Hi, > >I was mulling over the renumbering scenario for hosts that use >stateless autoconf for address allocation and DHCPv6 Light (stateless >DHCPv6) for DNS options. > >Let's assume either the site renumbers, or the DNS servers are >renumbered. The latter case means that you can't just use a new >prefix on an RA as a hint to re-request DNS options via DHCPv6 Light. > >With an RA method for DNS option configuration, you put the new DNS >option information in the RA. > >With DHCPv6 Light for DNS option configuration, how is the client told >that DNS options have changed? The reconfigure message seems to be >unicast to the clients, but if the DHCPv6 server is stateless, it won't >have a list of clients (with leased IPs) to send that Reconfigure >message to? > >Is this a general problem for any options set by a host that only uses >stateless DHCPv6 for options, and use RFC2462 for addresses. > >One option for passing the new DNS options from the DHCPv6 Light server >to the client is a multicast Reconfigure message. That would work >if the DHCPv6 Light server is on link, but if relays are used and there >is no multicast routing on site, this seems to be a gap (and a case for the >RA method - though of course with RA method you still need to reconfigure >the router for the new RA...) > >Thoughts? > >Tim > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 16:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20383; Thu, 13 Nov 2003 16:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOZP-0005uy-31; Thu, 13 Nov 2003 16:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOZI-0005tl-TQ for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 15:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20280 for ; Thu, 13 Nov 2003 15:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOZH-0005BL-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:59:55 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOZB-0005BB-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:59:49 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA23177; Thu, 13 Nov 2003 20:59:33 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA20671; Thu, 13 Nov 2003 20:59:32 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hADKxVk06530; Thu, 13 Nov 2003 20:59:31 GMT Date: Thu, 13 Nov 2003 20:59:31 +0000 From: Tim Chown To: SHIRASAKI Yasuhiro Cc: dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031113205931.GF3473@login.ecs.soton.ac.uk> Mail-Followup-To: SHIRASAKI Yasuhiro , dnsop@cafax.se, dhcwg@ietf.org References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <20031114.051205.48455194.yasuhiro@nttv6.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031114.051205.48455194.yasuhiro@nttv6.jp> User-Agent: Mutt/1.4i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Both setting the trigger of re-request on renumbering of prefix in RA, > and a multicast Reconfigure message might cause all nodes to rush on > the single DHCPv6-lite server for information-request reply exchange. > It could work with small number of clients though. I guess you could add some random delays, but you should also scale your DHCPv6 server provision to have multiple servers? I guess we can say that: (1) Automatic renumbering is broken if people hard-code data in clients (2) If a secure environment for reconfigure is needed, a multicast message adds some complexity (3) The Reconfigure message is really designed for a fully stateful DHCPv6 environment, not a purely stateless one providing options info (?) (4) Periodic polling of the DHCPv6 server by clients allows renumbering but is not a full solution for more rapid (unplanned) renumbering. (5) There isn't really a ethod now for a client to be informed of a renumbering event of a stateless DHCPv6 option (DNS, NTP) (6) We don't want to use RA method because that would also mean an NTP extension for RA (?) (7) If the network renumbers, statelessly configuring hosts should/could use the new prefix seen on an RA as a hint to re-request DHCPv6 options if the O bit is set. So is something overlooked, or do we not feel we need a solution to (5), given we could use (7)? Not sure how explicit (7) is... Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 16:26:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21423; Thu, 13 Nov 2003 16:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOyX-0007aa-8B; Thu, 13 Nov 2003 16:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOy6-0007Vb-Gj for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 16:25:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21360 for ; Thu, 13 Nov 2003 16:25:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOy4-0005az-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:25:32 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AKOy4-0005aw-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:25:32 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id 46DC71C02C2B; Thu, 13 Nov 2003 16:25:28 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA24294; Fri, 14 Nov 2003 02:54:11 +0530 (IST) Message-ID: <3FB3F6C0.2050205@india.hp.com> Date: Fri, 14 Nov 2003 02:55:20 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB3E69E.4060705@india.hp.com> <20031113205538.GA20348@sverresborg.uninett.no> In-Reply-To: <20031113205538.GA20348@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Fri, Nov 14, 2003 at 01:46:30AM +0530, Vijayabhaskar A K wrote: > > >>I guess, "stateless" means the server doesn't need to maintain the >>lifetime of the configuration information it has assigned to the clients >>and it doesn't mean that it doesn't need to maintain the information >>about the clients.. >> >> > >But it's certainly an advantage not having too. > > Considering the disadvantages due to mutlicast reconfigure, the gain is less... > > >>The proposal of sending multicast reconfigure message was discussed, but >>it was dropped as its very difficult to achieve multicast security and >>reconfigure mechanism mandates auth... >> >> > >You could have DHCP server multicast reconfigure to relays, that then >use link-scope multicast to send reconfiguration to the clients. DHCP >server could also possibly have a list of relays and use unicast to >the relays. > >Security shouldn't be a problem I think, you're only asking clients to >send requests, you're not giving the clients any config information. > > An intruder relay can trigger the clients to initiate the renewal of config info by sending the reconfigure message, leading to flooding of dhcp packets from all the dhcpv6 client nodes and DoS attack on the server... Thats the reason why Reconfigure message needs to be authenticated... Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 16:30:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21638; Thu, 13 Nov 2003 16:30:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKP2T-0007mn-KS; Thu, 13 Nov 2003 16:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKP29-0007lS-Gd for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 16:29:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21583 for ; Thu, 13 Nov 2003 16:29:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKP27-0005gL-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:29:43 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AKP26-0005gI-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:29:42 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 2CA1B1C016CB; Thu, 13 Nov 2003 13:29:40 -0800 (PST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA24525; Fri, 14 Nov 2003 02:58:24 +0530 (IST) Message-ID: <3FB3F7BD.7030301@india.hp.com> Date: Fri, 14 Nov 2003 02:59:33 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown Cc: SHIRASAKI Yasuhiro , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <20031114.051205.48455194.yasuhiro@nttv6.jp> <20031113205931.GF3473@login.ecs.soton.ac.uk> In-Reply-To: <20031113205931.GF3473@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tim Chown wrote: >>Both setting the trigger of re-request on renumbering of prefix in RA, >>and a multicast Reconfigure message might cause all nodes to rush on >>the single DHCPv6-lite server for information-request reply exchange. >>It could work with small number of clients though. >> >> > >I guess you could add some random delays, but you should also scale your >DHCPv6 server provision to have multiple servers? > >I guess we can say that: > >(1) Automatic renumbering is broken if people hard-code data in clients > >(2) If a secure environment for reconfigure is needed, a multicast message > adds some complexity > >(3) The Reconfigure message is really designed for a fully stateful DHCPv6 > environment, not a purely stateless one providing options info (?) > >(4) Periodic polling of the DHCPv6 server by clients allows renumbering > but is not a full solution for more rapid (unplanned) renumbering. > > Though, rapid renumbering is not more likely to happen, periodic polling will take some network bandwidth, >(5) There isn't really a ethod now for a client to be informed of a > renumbering event of a stateless DHCPv6 option (DNS, NTP) > >(6) We don't want to use RA method because that would also mean an NTP > extension for RA (?) > >(7) If the network renumbers, statelessly configuring hosts should/could > use the new prefix seen on an RA as a hint to re-request DHCPv6 > options if the O bit is set. > >So is something overlooked, or do we not feel we need a solution to (5), >given we could use (7)? Not sure how explicit (7) is... > > I guess, (7) is better than inventing a solution for (5)... The client can assume the prefix change mean, there is a very good chance that some of the configuration information may have changed and it can go ahead and initiate re-request in the case O bit is set in RAs.. Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 17:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23237; Thu, 13 Nov 2003 17:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPcE-0001m3-NX; Thu, 13 Nov 2003 17:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLLM-0006oH-PN for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 12:33:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09586 for ; Thu, 13 Nov 2003 12:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLLL-0001Xl-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 12:33:19 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKLLJ-0001We-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 12:33:17 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AKLKl-0000Wv-00; Thu, 13 Nov 2003 09:32:43 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5XWDD>; Thu, 13 Nov 2003 09:32:36 -0800 Message-ID: From: "Kostur, Andre" To: "'Rentschler, Markus'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] ID's: DHCP Discovery Extensions Date: Thu, 13 Nov 2003 09:32:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AA0C.20D5D540" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AA0C.20D5D540 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de] > ---------------------------------------------------------------- > Thus by default, any device on the network would be able to trigger a > DDoS attack on your DHCP infrastructure by sending a broadcast > DHCPNETSCAN (again, we're talking about the proposed _default_ > configuration)? > > [MR>] > This security hole is indeed the most painful aspect of the Discovery > Extensions. > Besides the proposed bandwith limitation, a possible solution > could be: > DHCP is at startup by default issuing DHCPDISCOVER. As long > as the device > has no lease, broadcasted DHCPNETSCANs must not be answered. After the > device got its lease, only DHCPNETSCANs from the > lease-granting server will > be answered OR only after some authentication took place > (authentication > mechanism would have to be developed). So... in the absence of an authentication (of servers) mechanism (which according to this draft, _isn't_ a requirement), both the discovery and redundancy aspects of this draft are completely useless since devices won't answer NETSCANs from anybody other than their lease-granting server? > But this would eliminate one of the advantages of the > Discovery extensions: > No flooding mit DHCPDISCOVER messages at boot time and > configuration under > complete control of the server. Which would mean that devices which don't have a lease yet, cannot be discovered by NETSCAN. > What is your recommendation for the default settings from > your point of view Recall that my opinion is that the Discovery Extensions shouldn't exist... so my recommendation on what the default settings should be is fairly obvious :) > ? > So far the default settings where not that important to me. > In our environments (very restricted access and a maximum of > a few thousand > devices) I would just enable everything and be quite save as > long as the > Admin doesn't make nonsense himself. > Maybe one should explicitly restrict the Discovery Extensions > to such types > of networks? Can you think of another DHCP option/behaviour which has a similar restriction? > ---------------------------------------------------------------- > In which case, why doesn't the admin simply > enable DHCP to begin with. This would make DHCPCONFIGURE > redundant (the > device will already have a lease, or will DISCOVER soon. And accept > FORCERENEW (assuming RFC 3203 is implemented) ). > > [MR>] > I considered using the FORCERENEW instead of DHCPCONFIGURE in > the beginning. > I came up to dislike the FORCERENEW mechanism for the > following reasons: > It operates that way: The server who wants to initiate > reconfiguration tells > the client to ask at the same server for a new configuration! > A little bit > complicated, isn't it ? Especially for the server > implementation when it > wants so supervise the whole reconfiguration process! The FORCERENEW > mechanism leads to a seven (!) message exchange for the > reconfiguration of a > single(!) client ! > FORCERENEW -> DHCPREQUEST -> DHCPNAK -> DHCPDISCOVER -> DHCPOFFER -> > DHCPREQUEST -> DHCPACK > That produces a lot of superfluous network traffic. The > straightforward way > would be that the server tells the client it's new > configuration and gets an > ACK to be sure everything went ok. That's the way the > DHCPCONFIGURE/DHCPREPORT mechanism works which even provides > additional > flexibility besides that. However, keep in mind that the last 6 messages are all already existing messages and behaviours. No new behaviours would need to be programmed into DHCP Clients, Servers, or Relay Agents. They are all very well defined and implemented. Particularly with regards to tearing down and reconfiguring the IP stack. Also keep in mind that network reconfiguration is (or should be...) a fairly rare event. Seven messages once in a blue moon is not an issue. (There's also another draft currently being discussed with could cut it down to 5 messages). > And what happens when the server crashed and all the lease > info is lost ? > No possibility to get any information about clients with FORCERENEW > With DHCPNETSCAN one could easily recover the leae database > without the need > to boot up all the clients (which would be inacceptable anyway). Why is your lease info lost? Either it's reloaded from stable storage, or if the server goes up in flames, it's recovered from your failover partner. (If your entire server room goes up in flames, then you've got bigger problems than your clients rebooting). > ---------------------------------------------------------------- > The draft still has additional state transitions to document. For > example: upon receiving a DHCPNETSCAN in the BOUND state, the client > must transmit a DHCPREPORT and transition back to the BOUND > state. Upon > receiving a DHCPNETSCAN in the INIT-REBOOT state, do what? How about > SELECTING? The draft is proposing 3 new messages. The draft needs to > document what is going to happen in _every_ state of the DHCP client > state machine when it receives any of the 3 messages (OK, 2 messages, > clients shouldn't be getting REPORTs). > > [MR>] > OK, a state diagram with the extensions can be drawn. > I thought this was unnecessary since the behaviour of the Discovery > Extensions is so simple, that IMHO a textual description is far better > understandable than a state diagram made of ASCII characters. You'd be surprised at how things can be misinterpreted. :) > ---------------------------------------------------------------- > > > Another thought... what happens if the device sends the > > RELEASE, then > > > sends the REPORT, but the REPORT is lost? (keep in mind > > that this is all > > > UDP... UDP packets may get dropped). > > > > > [MR>] Then the server will have to retransmit its > DHCPCONFIGURE > > until it gets a DHCPREPORT from that device. > > Since this is done on layer 2, it is not important if > the device > > accepted the initial DHCPCONFIGURE or still uses it's old or > > no ip address at all. > However, in the meantime there's a DHCP device out there that > has an IP > address, which the DHCP server has no valid lease for. This opens up > the possibility of duplicate IP address allocation. > > [MR>] > I don't agree on that. > The first IP that was RELEASEed is not longer in use, since the device > accepted the new ip setting. > The server has no valid lease on that new ip setting, but it > knows that the > REPORT is outstanding > and must of course not give that ip address to another client > until its > recovery mechanism timed out. And additionally there is still OK, so there's a bunch more logic and states on individual IPs that the server must now maintain. > the mechanism > that DHCP should check via an ARP request if an IP address is > already in > use. ARP doesn't help if the device is on the other side of a router.... (and if I recall correctly, the suggested method of detection for servers is ICMP Echo. ARP is suggested for _clients_ detecting duplicates). > ---------------------------------------------------------------- > > > > [MR>] > > > > Both should be possible: configuration AND > reconfiguration, > > > We already have a mechanism for reconfiguration. Why > > reinvent the wheel, > > > which only adds additional overhead? > > > > > [MR>] Sure, but there is no mechanism for server-originated > > CONfiguration. That's what the draft is all about. > If the device is configured to use DHCP anyway, you only need to wait > until the device performs a DISCOVER. > > [MR>] > What about the scenario that Lease Duration is infinite, the > Server has Infinite lease.... two things. One: your server admin shouldn't be using infinite leases if the network configuration is going to change. Two: RFC 3203. A FORCERENEW would still cause the client to renew its lease immediately. > crashed and lost its lease information ? Or an additional Already addressed. Either it's reloaded from stable storage, or recovered from the failover partner. > server is plugged > onto a running network ? Or a network is going to be > reorganized/reconfigured/altered without booting all clients ? If you're reconfiguring the network, all of your clients are going to effectively be rebooted anyway (from a networking perspective....). And 3203 is still good for this.... > ---------------------------------------------------------------- > > > one mildly malicious user can emit a NETSCAN once an hour > and cause your > > > entire network of 200000 devices to DDoS your real DHCP server by > > > hammering it with 200000 REPORTs, > > > > > [MR>] That is the only point that makes me some > headache too. > > I would like to get some ideas how this potential > > danger could be minimised. > > With normal DHCP we got a similar Problem at bootup, > when every > > client emits it DHCPDISCOVER messages. > > Granted, if your entire network is rebooting, the servers > will undergo a > severe load. However this would (hopefully) be a fairly rare event. > With this proposed draft, it even suggests initiating this load on a > periodic basis! > > [MR>] > I see there no real difference to what a management software does > that is periodically PINGing its network to check if all > agents are still > responding. PINGs are a lot more lightweight than a full DHCP exchange. They also don't involve broadcasting to everyone. > ---------------------------------------------------------------- > > > > > OK, what happens in the case: > > > > > 1) Device A sends the RELEASE > > > > > 2) Device B Discovers & Requests (since the IP is now > > > > available, it was > > > > > just released!) the now released IP > > > > > 3) Device A REPORTs on that IP ? > > > > [MR>] > > > > The REPORT must of course use the new IP assigned with > > > > DHCPCONFIGURE, since it is the REPORT's main job to tell the > > > > rest of the network that a certain client has a certain > > configuration. > > > > So there should be no problem. > > > There's a big problem. There is now two devices with the > > same IP address. > > > > > > > > [MR>] > > How do you get that idea ?? > > Device A has released the IP, since it got a DHCPCONFIGURE > > with new settings AND accepted them (Otherwise there > would be no > > RELEASE). > > So only Device B has this IP. > > Not necessarily true. Device A gets a DHCPCONFIGURE to > change it's DNS > settings. Since Device A has a current lease, the draft says that it > needs to DHCPRELEASE it first. Now the DHCP server has > released the IP, > but the client is still using the IP. Device B comes and does a > DISCOVER/REQUEST, receiving that IP. Presto, duplicate IP. > > [MR>] > Well, how long does Device A still have the old ip after DHCPRELEASE ? > 0.001 seconds ?-) That .001 is an eternity. DHCP servers may have to deal with hundreds to thousands of DHCP requests per second (in some environments). > The next operation in the code would of course be setting up > the ip stack > with the new parameters. Right, but the DHCP server barely knows about this. (If you have the additional states in the DHCP server to remember that this IP is pending a REPORT....). Which leads to another (much less likely case): What if a device receives a CONFIGURE, emits the RELEASE, then keeps trying to REPORT on the new IP, but the REPORTS keep getting lost? That would result in a client using an IP address that the server doesn't know about (the configuration has timed out, thus the server is no longer holding aside the IP). > ---------------------------------------------------------------- > > > Then it is a different protocol, and should be treated as such. > > > > > [MR>] It does the same (configuring the client with > ip and some > other parameters), > > just in a slightly different way that offers some additional > opportunities for network administrators. > > So far, I don't see the advantage of using this particular scheme over > the already specified RFC 3203. I think that 3203 has some > elegance in > it that it reuses as much of the existing DHCP infrastructure as > possible. > > [MR>] > I agree that RFC 3203 has some elegance in terms of simple > incorporation > into the DHCP client. And servers.... (and relays wouldn't need to be touched) > I think it was designed on this premise: > As much client-initiated behaviour as possible, even when the > intention is Yep. Much easier to change the server than the client (there's a lot fewer servers out there than clients....) > doing server-initiated reconfiguration. That's the reason why > in the end we > come up with a seven message exchange for a simple > reconfiguration that > could be done with two messages. However it's a seven message exchange where all of the implications are well understood... > ---------------------------------------------------------------- > Instead of the FORCERENEW attempting to do everything, it > only triggers the client to renew immediately, instead of waiting for > the full lease time. > > [MR>] RFC 3203 is an elegant solution for exactly that > purpose, but beyond > that IMHO it reaches it's limitations very quickly. > > ---------------------------------------------------------------- > Results in the client doing a unicast RENEW, which > if all you're changing is the DNS settings, the client could > easily only > change the DNS settings resulting in as little disruption to > IP services > as possible (client implementation detail...). And if you're chaging > the IP settings, the device would get a normal NAK to the request, > causing the client to perform all the normal DHCP behaviours > associated > with the NAK. > > [MR>] > Sure, this mechanism works and is very easy to implement on > clients, but on > what costs ? > Lots of messages get exchanged and the server has to > incorporate a very > complicated state machine to supervise the reconfiguration process. Uh, _what_ complicated state machine? Server sends a RECONFIGURE to client. Server remembers that it has sent a RECONFIGURE to the client. If the client has not responded with a REQUEST, retry. If a total timer has expired, give up. If a client responds with a REQUEST, note that the RECONFIGURE has been answered, and do all the normal DHCP stuff. That's a pretty easy behaviour change. > Do you know of any publicly available servers that support RFC 3203 ? 3203 mandates the use of 3118. There are no known implementations of 3118 on either a server or client. > ---------------------------------------------------------------- > This draft seems to imply that a device _must_ have a DHCP > state machine > running, even if the device isn't going to be using DHCP. > [MR] > In this case the device IS going to use DHCP (Discovery > Extensions), but not > sending initial DHCPDISCOVER messages. > This is simply to avoid flooding the network at boot time mit > DHCPDISCOVER > messages and doing the configuration under the control of the Server. > > If the device is already using DHCP, then this draft is redundant with > other, > already specified behaviours (Failover, RFC 3203, RFC 2131) > (Again, if > the device is already using DHCP, it will DISCOVER on it's own, or it > will have an established lease). > > [MR>] > Again, my scenario with the crashed server and the > device/topology detection > possibility. > This is only solveable with the Discovery mechanism > (DHCPNETSCAN/DHCPREPORT). The device/topology detection in this case _only_ works if _every_ device implements the Discovery Extensions. > The combination DHCPCONFIGURE/DHCPREPORT is IMHO a much > better solution to > the server-initiated configuration problem than the RFC 3203 > mechanism that > is IMHO more or less a workaround to the dogma of traditional > DHCP that the > client must initate communication. I don't think you've fully established that client-initiated communication is that much of a problem. > The redundancy mechanism is an additional goodie that the discovery > mechanism COULD provide. Again, we already _have_ a redundancy mechanism. DHCP Failover. > And I can think of a variety of other useful applications of > the Discovery > Extensions, I just dont't want to name them here for not > feeding potential > competitors too much. > > I regard the Discovery Protocol as a powerful thing that > offers a lot of > potential applications. > And since it performs the same task than DHCP (Dynamic Host > Configuration), > it is IMHO in the right place as a configurable extension to DHCP , > especially since the DHCP packet format and infratructure > (relay agents) can > be used for implementation with very little effort. > > Im aware of it's cons (DDoS through DHCPNETSCAN) and recommend that it > should only be used in environments where such an attack is > unlikely to > occur (networks with restricted access). Problem is... that's not the only place that DHCP is being used. ------_=_NextPart_001_01C3AA0C.20D5D540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] ID's: DHCP Discovery Extensions

> -----Original Message-----
> From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.= de]
> = ----------------------------------------------------------------
> Thus by default, any device on the network = would be able to trigger a
> DDoS attack on your DHCP infrastructure by = sending a broadcast
> DHCPNETSCAN (again, we're talking about the = proposed _default_
> configuration)?
>
> [MR>]
> This security hole is indeed the most painful = aspect of the Discovery
> Extensions.
> Besides the proposed bandwith limitation, a = possible solution
> could be:
> DHCP is at startup by default issuing = DHCPDISCOVER. As long
> as the device
> has no lease, broadcasted DHCPNETSCANs must not = be answered. After the
> device got its lease, only DHCPNETSCANs from = the
> lease-granting server will
> be answered OR only after some authentication = took place
> (authentication
> mechanism would have to be developed).

So... in the absence of an authentication (of = servers) mechanism (which according to this draft, _isn't_ a = requirement), both the discovery and redundancy aspects of this draft = are completely useless since devices won't answer NETSCANs from anybody = other than their lease-granting server?

> But this would eliminate one of the advantages = of the
> Discovery extensions:
> No flooding mit DHCPDISCOVER messages at boot = time and
> configuration under
> complete control of the server.

Which would mean that devices which don't have a = lease yet, cannot be discovered by NETSCAN.
 
> What is your recommendation for the default = settings from
> your point of view

Recall that my opinion is that the Discovery = Extensions shouldn't exist... so my recommendation on what the default = settings should be is fairly obvious :)

> ?
> So far the default settings where not that = important to me.
> In our environments (very restricted access and = a maximum of
> a few thousand
> devices) I would just enable everything and be = quite save as
> long as the
> Admin doesn't make nonsense himself.
> Maybe one should explicitly restrict the = Discovery Extensions
> to such types
> of networks?

Can you think of another DHCP option/behaviour which = has a similar restriction?

> = ----------------------------------------------------------------
> In which case, why doesn't the admin = simply
> enable DHCP to begin with.  This would = make DHCPCONFIGURE
> redundant (the
> device will already have a lease, or will = DISCOVER soon.  And accept
> FORCERENEW (assuming RFC 3203 is implemented) = ).
>
> [MR>]
> I considered using the FORCERENEW instead of = DHCPCONFIGURE in
> the beginning.
> I came up to dislike the FORCERENEW mechanism = for the
> following reasons:
> It operates that way: The server who wants to = initiate
> reconfiguration tells
> the client to ask at the same server for a new = configuration!
> A little bit
> complicated, isn't it ? Especially for the = server
> implementation when it
> wants so supervise the whole reconfiguration = process!  The FORCERENEW
> mechanism leads to a seven (!) message exchange = for the
> reconfiguration of a
> single(!) client !
> FORCERENEW -> DHCPREQUEST -> DHCPNAK = -> DHCPDISCOVER -> DHCPOFFER ->
> DHCPREQUEST -> DHCPACK
> That produces a lot of superfluous network = traffic. The
> straightforward way
> would be that the server tells the client it's = new
> configuration and gets an
> ACK to be sure everything went ok. That's the = way the
> DHCPCONFIGURE/DHCPREPORT mechanism works which = even provides
> additional
> flexibility besides that.

However, keep in mind that the last 6 messages are = all already existing messages and behaviours.  No new behaviours = would need to be programmed into DHCP Clients, Servers, or Relay = Agents.  They are all very well defined and implemented.  = Particularly with regards to tearing down and reconfiguring the IP = stack.  Also keep in mind that network reconfiguration is (or = should be...) a fairly rare event.  Seven messages once in a blue = moon is not an issue.  (There's also another draft currently being = discussed with could cut it down to 5 messages).

> And what happens when the server crashed and all = the lease
> info is lost ?
> No possibility to get any information about = clients with FORCERENEW
> With DHCPNETSCAN one could easily recover the = leae database
> without the need
> to boot up all the clients (which would be = inacceptable anyway).

Why is your lease info lost?  Either it's = reloaded from stable storage, or if the server goes up in flames, it's = recovered from your failover partner.  (If your entire server room = goes up in flames, then you've got bigger problems than your clients = rebooting).

> = ----------------------------------------------------------------
> The draft still has additional state = transitions to document.  For
> example: upon receiving a DHCPNETSCAN in the = BOUND state, the client
> must transmit a DHCPREPORT and transition back = to the BOUND
> state.  Upon
> receiving a DHCPNETSCAN in the INIT-REBOOT state= , do what?   How about
> SELECTING?  The draft is proposing 3 new = messages.  The draft needs to
> document what is going to happen in _every_ = state of the DHCP client
> state machine when it receives any of the 3 = messages (OK, 2 messages,
> clients shouldn't be getting REPORTs).
>
> [MR>]
> OK, a state diagram with the extensions can be = drawn.
> I thought this was unnecessary since the = behaviour of the Discovery
> Extensions is so simple, that IMHO a textual = description is far better
> understandable than a state diagram made of = ASCII characters.

You'd be surprised at how things can be = misinterpreted. :)

> = ----------------------------------------------------------------
> > > Another thought... what happens if = the device sends the
> > RELEASE, then
> > > sends the REPORT, but the REPORT is = lost?  (keep in mind
> > that this is all
> > > UDP... UDP packets may get dropped). =
> > >
> >       = [MR>]  Then the server will have to retransmit its
> DHCPCONFIGURE
> > until it gets a DHCPREPORT from that = device.
> >       Since = this is done on layer 2, it is not important if
> the device
> > accepted the initial DHCPCONFIGURE or = still uses it's old or
> > no ip address at all.
> However, in the meantime there's a DHCP device = out there that
> has an IP
> address, which the DHCP server has no valid = lease for.  This opens up
> the possibility of duplicate IP address = allocation.
>
> [MR>]
> I don't agree on that.
> The first IP that was RELEASEed is not longer = in use, since the device
> accepted the new ip setting.
> The server has no valid lease on that new ip = setting, but it
> knows that the
> REPORT is outstanding
> and must of course not give that ip address to = another client
> until its
> recovery mechanism timed out. And additionally = there is still

OK, so there's a bunch more logic and states on = individual IPs that the server must now maintain.

> the mechanism
> that DHCP should check via an ARP request if an = IP address is
> already in
> use.

ARP doesn't help if the device is on the other side = of a router.... (and if I recall correctly, the suggested method of = detection for servers is ICMP Echo.  ARP is suggested for = _clients_ detecting duplicates).

> = ----------------------------------------------------------------
> > > = >       [MR>]
> > > = >       Both should be possible: = configuration AND
> reconfiguration,
> > > We already have a mechanism for = reconfiguration.  Why
> > reinvent the wheel,
> > > which only adds additional overhead? =
> > >
> >       = [MR>]  Sure, but there is no mechanism for server-originated =
> > CONfiguration. That's what the draft is = all about.
> If the device is configured to use DHCP anyway, = you only need to wait
> until the device performs a DISCOVER.  =
>
> [MR>]
> What about the scenario that Lease Duration is = infinite, the
> Server has

Infinite lease.... two things.  One: your server = admin shouldn't be using infinite leases if the network configuration = is going to change.  Two: RFC 3203.  A FORCERENEW would still = cause the client to renew its lease immediately.

> crashed and lost its lease information ? Or an = additional

Already addressed.  Either it's reloaded from = stable storage, or recovered from the failover partner.

> server is plugged
> onto a running network ? Or a network is going = to be
> reorganized/reconfigured/altered without = booting all clients ?

If you're reconfiguring the network, all of your = clients are going to effectively be rebooted anyway (from a networking = perspective....).   And 3203 is still good for = this....

> = ----------------------------------------------------------------
> > > one mildly malicious user can emit a = NETSCAN once an hour
> and cause your
> > > entire network of 200000 devices to = DDoS your real DHCP server by
> > > hammering it with 200000 REPORTs, =
> > >
> >       = [MR>]  That is the only point that makes me some
> headache too.
> >       I = would like to get some ideas how this potential
> > danger could be minimised.
> >       With = normal DHCP we got a similar Problem at bootup,
> when every
> > client emits it DHCPDISCOVER messages. =
>
> Granted, if your entire network is rebooting, = the servers
> will undergo a
> severe load.  However this would = (hopefully) be a fairly rare event.
> With this proposed draft, it even suggests = initiating this load on a
> periodic basis!
>
> [MR>]
>  I see there no real difference to what a = management software does
> that is periodically PINGing its network to = check if all
> agents are still
> responding.

PINGs are a lot more lightweight than a full DHCP = exchange.  They also don't involve broadcasting to = everyone.

> = ----------------------------------------------------------------
> > > > > OK, what happens in the = case:
> > > > > 1) Device A sends the = RELEASE
> > > > > 2) Device B Discovers & = Requests (since the IP is now
> > > > available, it was
> > > > > just released!) the now = released IP
> > > > > 3) Device A REPORTs on that = IP ?
> > > = >       [MR>] 
> > > = >       The REPORT must of course use = the new IP assigned with
> > > > DHCPCONFIGURE, since it is the = REPORT's main job to tell the
> > > > rest of the network that a = certain client has a certain
> > configuration. 
> > > > So there should be no problem. =
> > > There's a big problem.  There is = now two devices with the
> > same IP address.
> > >
> > >
> >       = [MR>]
> >       How do = you get that idea ??
> >       Device = A has released the IP, since it got a DHCPCONFIGURE
> >       with = new settings AND accepted them (Otherwise there
> would be no
> > RELEASE).
> >       So = only Device B has this IP.
>
> Not necessarily true.  Device A gets a = DHCPCONFIGURE to
> change it's DNS
> settings.  Since Device A has a current = lease, the draft says that it
> needs to DHCPRELEASE it first.  Now the = DHCP server has
> released the IP,
> but the client is still using the IP.  = Device B comes and does a
> DISCOVER/REQUEST, receiving that IP.  = Presto, duplicate IP.
>
> [MR>]
> Well, how long does Device A still have the old = ip after DHCPRELEASE ?
> 0.001 seconds ?-)

That .001 is an eternity.   DHCP servers = may have to deal with hundreds to thousands of DHCP requests per second = (in some environments).

> The next operation in the code would of course = be setting up
> the ip stack
> with the new parameters.

Right, but the DHCP server barely knows about = this.  (If you have the additional states in the DHCP server to = remember that this IP is pending a REPORT....).  Which leads to = another (much less likely case):  What if a device receives a = CONFIGURE, emits the RELEASE, then keeps trying to REPORT on the new = IP, but the REPORTS keep getting lost?  That would result in a = client using an IP address that the server doesn't know about (the = configuration has timed out, thus the server is no longer holding aside = the IP).

> = ----------------------------------------------------------------
> > > Then it is a different protocol, and = should be treated as such.
> > >
> >       = [MR>]  It does the same (configuring the client with
> ip and some
> other parameters),
> >       just = in a slightly different way that offers some additional
> opportunities for network administrators. =
>
> So far, I don't see the advantage of using this = particular scheme over
> the already specified RFC 3203.  I think = that 3203 has some
> elegance in
> it that it reuses as much of the existing DHCP = infrastructure as
> possible.
>
> [MR>]
> I agree that RFC 3203 has some elegance in = terms of simple
> incorporation
> into the DHCP client.

And servers.... (and relays wouldn't need to be = touched)

> I think it was designed on this premise:
> As much client-initiated behaviour as possible, = even when the
> intention is

Yep.  Much easier to change the server than the = client (there's a lot fewer servers out there than clients....)

> doing server-initiated reconfiguration. That's = the reason why
> in the end we
> come up with a seven message exchange for a = simple
> reconfiguration that
> could be done with two messages.

However it's a seven message exchange where all of = the implications are well understood...
 
> = ----------------------------------------------------------------
>  Instead of the FORCERENEW attempting to = do everything, it
> only triggers the client to renew immediately, = instead of waiting for
> the full lease time.
>
> [MR>] RFC 3203 is an elegant solution for = exactly that
> purpose, but beyond
> that IMHO it reaches it's limitations very = quickly.
>
> = ----------------------------------------------------------------
>  Results in the client doing a unicast = RENEW, which
> if all you're changing is the DNS settings, the = client could
> easily only
> change the DNS settings resulting in as little = disruption to
> IP services
> as possible (client implementation = detail...).  And if you're chaging
> the IP settings, the device would get a normal = NAK to the request,
> causing the client to perform all the normal = DHCP behaviours
> associated
> with the NAK.
>
> [MR>]
> Sure, this mechanism works and is very easy to = implement on
> clients, but on
> what costs ?
> Lots of messages get exchanged and the server = has to
> incorporate a very
> complicated state machine to supervise the = reconfiguration process.

Uh, _what_ complicated state machine?  Server = sends a RECONFIGURE to client.  Server remembers that it has sent = a RECONFIGURE to the client.  If the client has not responded with = a REQUEST, retry.  If a total timer has expired, give up.  If = a client responds with a REQUEST, note that the RECONFIGURE has been = answered, and do all the normal DHCP stuff.  That's a pretty easy = behaviour change.

> Do you know of any publicly available servers = that support RFC 3203 ?

3203 mandates the use of 3118.  There are no = known implementations of 3118 on either a server or client.

> = ----------------------------------------------------------------
> This draft seems to imply that a device _must_ = have a DHCP
> state machine
> running, even if the device isn't going to be = using DHCP.
> [MR]
> In this case the device IS going to use DHCP = (Discovery
> Extensions), but not
> sending initial DHCPDISCOVER messages.
> This is simply to avoid flooding the network at = boot time mit
> DHCPDISCOVER
> messages and doing the configuration under the = control of the Server.
>
> If the device is already using DHCP, then this = draft is redundant with
> other,
> already specified behaviours (Failover, RFC = 3203, RFC 2131) 
> (Again, if
> the device is already using DHCP, it will = DISCOVER on it's own, or it
> will have an established lease).
>
> [MR>]
> Again, my scenario with the crashed server and = the
> device/topology detection
> possibility.
> This is only solveable with the Discovery = mechanism
> (DHCPNETSCAN/DHCPREPORT).

The device/topology detection in this case _only_ = works if _every_ device implements the Discovery Extensions.
 
> The combination DHCPCONFIGURE/DHCPREPORT is = IMHO a much
> better solution to
> the server-initiated configuration problem than = the RFC 3203
> mechanism that
> is IMHO more or less a workaround to the dogma = of traditional
> DHCP that the
> client must initate communication.

I don't think you've fully established that = client-initiated communication is that much of a problem.
 
> The redundancy mechanism is an additional = goodie that the discovery
> mechanism COULD provide.

Again, we already _have_ a redundancy = mechanism.  DHCP Failover.

> And I can think of a variety of other useful = applications of
> the Discovery
> Extensions, I just dont't want to name them = here for not
> feeding potential
> competitors too much.
>
> I regard the Discovery Protocol as a powerful = thing that
> offers a lot of
> potential applications.
> And since it performs the same task than DHCP = (Dynamic Host
> Configuration),
> it is IMHO in the right place as a configurable = extension to DHCP ,
> especially since the DHCP packet format and = infratructure
> (relay agents) can
> be used for implementation with very little = effort.
>
> Im aware of it's cons (DDoS through = DHCPNETSCAN) and recommend that it
> should only be used in environments where such = an attack is
> unlikely to
> occur (networks with restricted access).

Problem is... that's not the only place that DHCP is = being used.

------_=_NextPart_001_01C3AA0C.20D5D540-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 17:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23236; Thu, 13 Nov 2003 17:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPcD-0001lu-Rm; Thu, 13 Nov 2003 17:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIFH-00049i-Gj for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 09:14:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27581; Thu, 13 Nov 2003 09:14:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIFF-0005PR-00; Thu, 13 Nov 2003 09:14:49 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIFE-0005Os-00; Thu, 13 Nov 2003 09:14:48 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADEDfI04438; Thu, 13 Nov 2003 16:13:41 +0200 Date: Thu, 13 Nov 2003 16:13:41 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: iesg@ietf.org, Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard In-Reply-To: <4.3.2.7.2.20031113074713.01e59b18@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 13 Nov 2003, Ralph Droms wrote: > Pekka - thanks for your review. My responses to your comments are inline. Thanks.. just a few responses inline. (Btw -- does the case I mentioned off-line about first-hop router being a stateless DHCP server, but acting as DHCP relay for stateful DHCP need to be explicitly mentioned -- I guess so?) > At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote: > >On Thu, 30 Oct 2003, The IESG wrote: > >1) the spec is not sufficiently clear how the relays behave in a mixed world > >of stateless/stateful DHCP service. That is, would deploying a > >stateless-only relay (if such a thing is possible?) harm the stateful DHCP > >clients? Is the implementation of a relay any different for full/stateless > >DHCP service, etc. ?: > > > > The operation of relay agents is the same for stateless and stateful > > DHCPv6 service. The operation of relay agents is described in the > > DHCPv6 specification. > > The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are > all completely defined in RFC 3315. From the point of view of the > DHCPv6 relay agent, there is no difference between the subset of > RFC 3315 referred to as "stateless DHCPv6" and the full set of > functions in RFC 3315. > > More concisely, there are just "DHCPv6 relay agents" that work with both > full RFC 3315 clients and stateless-only clients... Right. I think this should be spelled out in the stateless document a bit better, that the stateless DHCP has to implement "full" relay service, which is of course rather lightweight in itself (it has no state, I believe). > >==> that is, do relays really *flood* these messages to all the DHCPv6 > >servers they know, so that if one doesn't process the request but silently > >ignores it, the others can step up and handle the job? See also the point > >1) above. > > Yes, a relay agent forwards a copy of each message it receives from a client > to each of the servers in its configured list of servers. Are all the responses equally flooded back to the relay as well? Does the relay pick and respond to the hosts with first or all the information? (Just trying to clarify, this probably doesn't need changes in the spec.) > > 1-4: give an introduction to DHCPv6 and an overview of DHCP message > > flows > > > >==> some of those flows are redundant to Stateless DHCPv6 operation, > >though.. :-) > > OK, would a more precise list (e.g., individual subsections rather than > simply "1-4") be helpful? That might not hurt. However, what I was referring to was that e.g. "message flows" or sections like do not really reflect the stateless DHCP operation... -- 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-admin@ietf.org Thu Nov 13 17:07:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23266; Thu, 13 Nov 2003 17:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPcH-0001md-PZ; Thu, 13 Nov 2003 17:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOVn-0005jy-4E for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 15:56:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20067 for ; Thu, 13 Nov 2003 15:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOVk-00055U-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:56:17 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AKOVk-000546-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:56:16 -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 hADKtdpI025078; Thu, 13 Nov 2003 21:55:39 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hADKtcR7020362; Thu, 13 Nov 2003 21:55:38 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hADKtck6020361; Thu, 13 Nov 2003 21:55:38 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 13 Nov 2003 21:55:38 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031113205538.GA20348@sverresborg.uninett.no> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB3E69E.4060705@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB3E69E.4060705@india.hp.com> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, Nov 14, 2003 at 01:46:30AM +0530, Vijayabhaskar A K wrote: > I guess, "stateless" means the server doesn't need to maintain the > lifetime of the configuration information it has assigned to the clients > and it doesn't mean that it doesn't need to maintain the information > about the clients.. But it's certainly an advantage not having too. > The proposal of sending multicast reconfigure message was discussed, but > it was dropped as its very difficult to achieve multicast security and > reconfigure mechanism mandates auth... You could have DHCP server multicast reconfigure to relays, that then use link-scope multicast to send reconfiguration to the clients. DHCP server could also possibly have a list of relays and use unicast to the relays. Security shouldn't be a problem I think, you're only asking clients to send requests, you're not giving the clients any config information. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 17:35:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25050; Thu, 13 Nov 2003 17:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ3J-0004AX-Jf; Thu, 13 Nov 2003 17:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ2p-00049Q-9x for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 17:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24992 for ; Thu, 13 Nov 2003 17:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ2m-0006rt-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 17:34:28 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ2m-0006rp-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 17:34:28 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 2199D1C010AF; Thu, 13 Nov 2003 14:34:25 -0800 (PST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id EAA28150; Fri, 14 Nov 2003 04:03:08 +0530 (IST) Message-ID: <3FB406E8.6020200@india.hp.com> Date: Fri, 14 Nov 2003 04:04:16 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB3E69E.4060705@india.hp.com> <20031113205538.GA20348@sverresborg.uninett.no> <3FB3F6C0.2050205@india.hp.com> <20031113214047.GA20420@sverresborg.uninett.no> In-Reply-To: <20031113214047.GA20420@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Fri, Nov 14, 2003 at 02:55:20AM +0530, Vijayabhaskar A K wrote: > > >>An intruder relay can trigger the clients to initiate the renewal of >>config info by sending the reconfigure message, leading to flooding of >>dhcp packets from all the dhcpv6 client nodes and DoS attack on the >>server... Thats the reason why Reconfigure message needs to be >>authenticated... >> >> > >Ah ok, I see. One could possibly do authentication for multicasted >messages too, but the current authentication method wouldn't work >I think. > >Stig > > > > There is some work going on multicast security, http://www.ietf.org/html.charters/msec-charter.html It could be used here... Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 17:52:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23275; Thu, 13 Nov 2003 17:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPcJ-0001qP-I9; Thu, 13 Nov 2003 17:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPDS-0000KA-KR for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 16:41:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22104 for ; Thu, 13 Nov 2003 16:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPDQ-0005rB-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:41:24 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AKPDQ-0005qp-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 16:41:24 -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 hADLempI000798; Thu, 13 Nov 2003 22:40:48 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hADLemR7020468; Thu, 13 Nov 2003 22:40:48 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hADLelZg020467; Thu, 13 Nov 2003 22:40:47 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 13 Nov 2003 22:40:47 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031113214047.GA20420@sverresborg.uninett.no> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB3E69E.4060705@india.hp.com> <20031113205538.GA20348@sverresborg.uninett.no> <3FB3F6C0.2050205@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB3F6C0.2050205@india.hp.com> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, Nov 14, 2003 at 02:55:20AM +0530, Vijayabhaskar A K wrote: > An intruder relay can trigger the clients to initiate the renewal of > config info by sending the reconfigure message, leading to flooding of > dhcp packets from all the dhcpv6 client nodes and DoS attack on the > server... Thats the reason why Reconfigure message needs to be > authenticated... Ah ok, I see. One could possibly do authentication for multicasted messages too, but the current authentication method wouldn't work I think. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 13 17:52:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23238; Thu, 13 Nov 2003 17:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPcF-0001mL-UY; Thu, 13 Nov 2003 17:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNik-0001E6-9G for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 15:05:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16301 for ; Thu, 13 Nov 2003 15:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNie-00044M-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:05:32 -0500 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AKNid-00043i-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 15:05:31 -0500 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hADK4ted060122; Thu, 13 Nov 2003 21:04:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20031113191145.GS3473@login.ecs.soton.ac.uk> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, dnsop@cafax.se From: Iljitsch van Beijnum Date: Thu, 13 Nov 2003 14:05:11 -0600 To: Tim Chown X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 13-nov-03, at 13:11, Tim Chown wrote: > With DHCPv6 Light for DNS option configuration, how is the client told > that DNS options have changed? Operationally, you'd probably have to support these addresses forever. Not just because of DHCP issues but also because users tend to jot down dynamic stuff and then hardcode it. (For instance for hosts that don't support dynamic DNS discovery (which obviously are almost all of them today (in IPv6)).) > One option for passing the new DNS options from the DHCPv6 Light server > to the client is a multicast Reconfigure message. Hm, I can already imagine the posters on the men's room at IETF 63: "whoever is sending "reconfigure DNS" multicast messages every second, quit it as the 1200 DHCPv6 requests per second are killing the wireless performance". There are DoS issues here. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 14 07:02:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07456; Fri, 14 Nov 2003 07:02:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKceH-0001Ga-Px; Fri, 14 Nov 2003 07:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKceG-0001GP-Dg for dhcwg@optimus.ietf.org; Fri, 14 Nov 2003 07:02:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07431 for ; Fri, 14 Nov 2003 07:01:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKceB-0003wa-00 for dhcwg@ietf.org; Fri, 14 Nov 2003 07:01:55 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AKceB-0003wX-00 for dhcwg@ietf.org; Fri, 14 Nov 2003 07:01:55 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 0126D1C00FB8 for ; Fri, 14 Nov 2003 07:01:53 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id RAA24875 for ; Fri, 14 Nov 2003 17:30:31 +0530 (IST) Message-ID: <3FB4C428.4050709@india.hp.com> Date: Fri, 14 Nov 2003 17:31:44 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DHCPWG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] IDs on remote boot option published Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All The IDs on remote boot option are published... http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-opt-rboot-00.txt http://www.ietf.org/internet-drafts/draft-vijay-dhc-opt-extrboot-00.txt Please have a look at it and let me know your comments.. Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 14 08:07:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08868; Fri, 14 Nov 2003 08:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKdfB-0004rF-H1; Fri, 14 Nov 2003 08:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKdec-0004pN-SB for dhcwg@optimus.ietf.org; Fri, 14 Nov 2003 08:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08770; Fri, 14 Nov 2003 08:06:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKdeb-0004cv-00; Fri, 14 Nov 2003 08:06:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AKdeb-0004cd-00; Fri, 14 Nov 2003 08:06:25 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAED5pxg001585; Fri, 14 Nov 2003 08:05:51 -0500 (EST) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-225.cisco.com [10.21.96.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADZ34468; Fri, 14 Nov 2003 08:05:49 -0500 (EST) Message-Id: <4.3.2.7.2.20031113213303.026f0448@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Nov 2003 08:05:44 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Cc: iesg@ietf.org, In-Reply-To: References: <4.3.2.7.2.20031113074713.01e59b18@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 04:13 PM 11/13/2003 +0200, Pekka Savola wrote: >On Thu, 13 Nov 2003, Ralph Droms wrote: > > Pekka - thanks for your review. My responses to your comments are inline. > >Thanks.. just a few responses inline. > >(Btw -- does the case I mentioned off-line about first-hop router being a >stateless DHCP server, but acting as DHCP relay for stateful DHCP need to >be explicitly mentioned -- I guess so?) Recognizing that a network element can be both a server and a relay agent has evolved in DHCPv4 without any explicit text - there's nothing in the DHPCv4 specifications that disallows such behavior. If there is consensus that text allowing a network element to act as both a DHCPv6 server and relay agent would be useful, we can add it to this doc... > > At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote: > > >On Thu, 30 Oct 2003, The IESG wrote: > > >1) the spec is not sufficiently clear how the relays behave in a mixed > world > > >of stateless/stateful DHCP service. That is, would deploying a > > >stateless-only relay (if such a thing is possible?) harm the stateful DHCP > > >clients? Is the implementation of a relay any different for > full/stateless > > >DHCP service, etc. ?: > > > > > > The operation of relay agents is the same for stateless and stateful > > > DHCPv6 service. The operation of relay agents is described in the > > > DHCPv6 specification. > > > > The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are > > all completely defined in RFC 3315. From the point of view of the > > DHCPv6 relay agent, there is no difference between the subset of > > RFC 3315 referred to as "stateless DHCPv6" and the full set of > > functions in RFC 3315. > > > > More concisely, there are just "DHCPv6 relay agents" that work with both > > full RFC 3315 clients and stateless-only clients... > >Right. I think this should be spelled out in the stateless document a bit >better, that the stateless DHCP has to implement "full" relay service, >which is of course rather lightweight in itself (it has no state, I >believe). I would rather add text like: This document does not apply to the behavior of DHCPv6 relay agents. > > >==> that is, do relays really *flood* these messages to all the DHCPv6 > > >servers they know, so that if one doesn't process the request but silently > > >ignores it, the others can step up and handle the job? See also the point > > >1) above. > > > > Yes, a relay agent forwards a copy of each message it receives from a > client > > to each of the servers in its configured list of servers. > >Are all the responses equally flooded back to the relay as well? Yes - in this regard a DHCPv6 relay agent works the same as a DHCPv4 relay agent. > Does the >relay pick and respond to the hosts with first or all the information? > >(Just trying to clarify, this probably doesn't need changes in the spec.) No. > > > 1-4: give an introduction to DHCPv6 and an overview of DHCP message > > > flows > > > > > >==> some of those flows are redundant to Stateless DHCPv6 operation, > > >though.. :-) > > > > OK, would a more precise list (e.g., individual subsections rather than > > simply "1-4") be helpful? > >That might not hurt. However, what I was referring to was that e.g. >"message flows" or sections like do not really reflect the stateless DHCP >operation... OK. - Ralph >-- >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-admin@ietf.org Fri Nov 14 09:14:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11017; Fri, 14 Nov 2003 09:14:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKei1-0000jo-HG; Fri, 14 Nov 2003 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeht-0000jS-TG for dhcwg@optimus.ietf.org; Fri, 14 Nov 2003 09:13:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10998 for ; Fri, 14 Nov 2003 09:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKehs-0005e0-00 for dhcwg@ietf.org; Fri, 14 Nov 2003 09:13:52 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AKehr-0005dx-00 for dhcwg@ietf.org; Fri, 14 Nov 2003 09:13:51 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAEEDXAr001627; Fri, 14 Nov 2003 09:13:49 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Tim Chown'" Cc: Subject: RE: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? Date: Fri, 14 Nov 2003 09:13:42 -0500 Message-ID: <000001c3aab9$85f259f0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <20031113205931.GF3473@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable There was some discussion about adding a "configuration lifetime" option = for Information-Request/Reply messages. This would be similar to the address lifetimes and the idea would be that this would give the client an indication of when to obtain updated configuration information. While = this does not solve the problem completely, it would help solve the problem = when scheduled changes in the network are planned. We may also want to have clients that initiate an Information-Request = after detecting a configuration change that may invalidate existing = information (such as prefixes in configuration information that are no longer valid) = use a random delay before sending the Information-Request (just as they = would for the 'first' Information-Request). Perhaps this just means clarifying what is meant in section 18.1.5 (RFC 3115) by first: The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. There are also larger issues here when renumbering happens as the client = may need to its DNS information (dynamic DNS), etc. So, when renumbering = happens (new addresses are added or old ones are deprecated), the client needs = to do some thinking and one of the outcomes is to obtain updated configuration information. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Thursday, November 13, 2003 4:00 PM To: SHIRASAKI Yasuhiro Cc: dnsop@cafax.se; dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? > Both setting the trigger of re-request on renumbering of prefix in RA, > and a multicast Reconfigure message might cause all nodes to rush on > the single DHCPv6-lite server for information-request reply exchange. > It could work with small number of clients though. I guess you could add some random delays, but you should also scale your DHCPv6 server provision to have multiple servers? I guess we can say that: (1) Automatic renumbering is broken if people hard-code data in clients (2) If a secure environment for reconfigure is needed, a multicast = message adds some complexity (3) The Reconfigure message is really designed for a fully stateful = DHCPv6 environment, not a purely stateless one providing options info (?) (4) Periodic polling of the DHCPv6 server by clients allows renumbering but is not a full solution for more rapid (unplanned) renumbering. (5) There isn't really a ethod now for a client to be informed of a renumbering event of a stateless DHCPv6 option (DNS, NTP) (6) We don't want to use RA method because that would also mean an NTP extension for RA (?) (7) If the network renumbers, statelessly configuring hosts should/could use the new prefix seen on an RA as a hint to re-request DHCPv6 options if the O bit is set. So is something overlooked, or do we not feel we need a solution to (5), given we could use (7)? Not sure how explicit (7) is... Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 14 11:07:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17634; Fri, 14 Nov 2003 11:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgTP-00024F-8T; Fri, 14 Nov 2003 11:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgTE-0001yW-Az for dhcwg@optimus.ietf.org; Fri, 14 Nov 2003 11:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17576; Fri, 14 Nov 2003 11:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgTB-0007me-00; Fri, 14 Nov 2003 11:06:49 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgTA-0007mb-00; Fri, 14 Nov 2003 11:06:49 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA17437; Fri, 14 Nov 2003 16:06:46 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA18201; Fri, 14 Nov 2003 16:06:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAEG6j419983; Fri, 14 Nov 2003 16:06:46 GMT Date: Fri, 14 Nov 2003 16:06:45 +0000 From: Tim Chown To: dhcwg@ietf.org, iesg@ietf.org Message-ID: <20031114160645.GE19013@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, iesg@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Oct 30, 2003 at 05:57:10PM -0500, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following document: > > - 'A Guide to Implementing Stateless DHCPv6 Service' > as a Proposed Standard Wrt recent exchanges on the dhcwg list, are we concerned that there is no mechanism in stateless DHCPv6 for the DHCPv6 server to inform DHCPv6 clients of renumbering events to DNS or NTP servers (for example) where the clients are using stateless autocinfiguration (RFC2462) for address assignment and DHCPv6 (stateless) for options (DNS, NTP, ...). If the clients use DHCPv6 for address assignment, the DHCPv6 server could use its IP lease information to unicast the Reconfigure message, but in a stateless-only DHCPv6 server this client information would presumably not be available. The current solution seems to be that clients must poll for changes, which is not ideal, but which may suffice in some cases. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 14 18:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06071; Fri, 14 Nov 2003 18:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKnq8-0004VU-Vs; Fri, 14 Nov 2003 18:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPrE-0003RH-Nf for dhcwg@optimus.ietf.org; Thu, 13 Nov 2003 17:22:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24438 for ; Thu, 13 Nov 2003 17:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPrC-0006fJ-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 17:22:30 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1AKPrB-0006f9-00 for dhcwg@ietf.org; Thu, 13 Nov 2003 17:22:29 -0500 Received: (qmail 71404 invoked from network); 13 Nov 2003 22:30:12 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 22:30:12 -0000 Message-ID: <3FB40486.8020608@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 07:24:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Tim Chown CC: dnsop@cafax.se, dhcwg@ietf.org References: <20031113191145.GS3473@login.ecs.soton.ac.uk> In-Reply-To: <20031113191145.GS3473@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tim Chown; I think that it is silently assumed that DHCPv6-lite is configured of DNS server addresses without relaying requests to others. That is, reconfiguration upon renumbering is necessary. Or, DHCPv6-lite may be (pre)configured with well known addresses, as I suggested at the last meeting. But, let's assume relaying is performed, which is a likely scenario on "stateful" cases, anyway. > One option for passing the new DNS options from the DHCPv6 Light server > to the client is a multicast Reconfigure message. That would work > if the DHCPv6 Light server is on link, but if relays are used and there > is no multicast routing on site, this seems to be a gap (and a case for the > RA method - though of course with RA method you still need to reconfigure > the router for the new RA...) W.r.t. inter-link multicast, what multicast protocols is intended to be used by people in DHC WG? If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes or is renumbered? Is a well known unicast address is assigned to a primary and a back-up CORE/RP/SS, which means ANYCAST. Is DVMRP assumed, instead? Or, will we wait until yet another multicast protocol is standardized, hoping that it will solve all the problems? Assuming that some multicast protocol solves all the problems, another question is on multicast address. Is it a well known multicast address? If so, is there any configuration necessary at a site (or something like that) border router? If so, what happens if a customer want to relay DHCP request to ISP's DHCP server? What happens the border router is wrongly configured? Masataka Ohta PS It seems to me that relying on multicast does not solve but merely refer the problem, which is better solved at the point (protocol) where it is observed. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From taxpress@mail.com Sat Nov 15 06:28:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04622 for ; Sat, 15 Nov 2003 06:28:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKybg-0006ZA-00 for dhc-archive@ietf.org; Sat, 15 Nov 2003 06:28:48 -0500 Received: from [203.162.21.114] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AKybb-0006YI-00 for dhc-archive@ietf.org; Sat, 15 Nov 2003 06:28:44 -0500 Reply-To: "ConstruNews" From: "Temas "Patrulhados"" To: dhc-archive@ietf.org Subject: Lindenberg: opiniões "politicamente incorretas", vêm sendo marginalizadas no debate nacional ref.: hkg 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: Sat, 15 Nov 2003 06:28:44 -0500

xym EnEspañol - InEnglish

Temas "patrulhados"

Opiniões "politicamente incorretas" vêm sendo marginalizadas no debate nacional, diz Lindenberg

* Patrulhamento...

Em meios empresariais e religiosos continua repercutindo o livro "Os católicos e a economia de mercado", de autoria de Adolpho Lindenberg. O trabalho denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, comentários, livros, reportagens e opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas sociais". Noutras palavras, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Antídoto

O antídoto para esta situação de violência psicológica e espiritual consiste na difusão - por meios alternativos, se preciso for - de informações idôneas, capazes de esclarecer a opinião pública e provocar debates construtivos. Com efeito, uma vez rompidos os anteparos da censura, cada um em seu próprio ambiente poderá, sem medo, manifestar sua opinião sobre os assuntos 'patrulhados'. É a proposta inovadora de um programa de libertação ideológica, impulsionado pela coragem, em defesa do esclarecimento popular.

* Esclarecimento!

Esse programa tem alcance prático, especialmente para os católicos. O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), que favorecem as invasões de terras promovidas pelos MST, bem como às repetidas críticas à Área de Livre Comércio das Américas (ALCA), às privatizações, à alegada ameaça das multinacionais e do capital estrangeiro, e até mesmo ao plantio de transgênicos, apresenta dois inconvenientes sérios. Em primeiro lugar, tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados. Em segundo, de que as teses da Teologia da Libertação têm fundamentos sólidos na doutrina católica. Tudo isso tem muita importância prática. Com efeito, na vasta rede de movimentos contestatários, ativa no país inteiro, a ala progressista religiosa se sobressai hoje como o setor mais ativo e mais radical nas proposições.

* Temáticas

Diante deste cenário e visando alertar a opinião pública católica, o livro acima citado procura debater as seguintes temáticas:

- Capitalismo, globalização, neoliberalismo e privatizações seriam os grandes responsáveis pelos bolsões de misérias, desigualdades sociais e dependência externa (isto é, dos Estados Unidos)?

- Os programas sociais estatais seriam a solução para combater a fome, o analfabetismo, o atraso e a indigência das classes mais pobres do Brasil?

- O materialismo, o anonimato, a exclusão social, o relacionamento burocrático entre as pessoas são causados muito especialmente pelo crescimento desordenado das cidades ou sobretudo pela descristianização de nossos hábitos?

* Informe-se!

Informe-se desses assuntos - e ainda de vários outros - no livro "Os católicos e a economia de mercado". Você pode adquiri-lo, clicando nos links abaixo. E complemente seus dados com artigos de Adolpho Lindenberg que lhe serão enviados gratuitamente (clique nos links abaixo). O autor analisa tais assuntos com base na doutrina social católica, expressa nas encíclicas: discorre sobre as relações entre a economia e a moral, liberdade e responsabilidade dos atos econômicos, direito de propriedade, respeito às leis naturais no mercado, liceidade do lucro, assistência social, relações humanas na empresa e na vida civil.

* Destaque

E, por fim, um ponto com merecido destaque em "Os católicos e a economia de mercado": como as reivindicações "sociais" têm como fim o socorro aos necessitados e a diminuição de desigualdades sociais, é indispensável ter em vista que esse objetivo só poderia ser alcançado com a elevação significativa do padrão de vida do povo (para o autor, por uma dose maior de capitalismo autêntico) e sobretudo pela recristianização da sociedade. A assistência aos necessitados deve, além do mais, sempre que possível, ter um tom pessoal, familiar, típico das sociedades orgânicas harmonicamente diferenciadas, das quais ainda se encontram reflexos vivos em antigas cidades do interior brasileiro. Ali ainda hoje subsistem hospitais, creches, asilos, de iniciativa religiosa e particular, que atendem aos necessitados de modo mais humano e eficaz que a assistência estatal prestada nas grandes metrópoles.

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 30 de novembro, usando qualquer um dos três links seguintes, serão sorteados 10 exemplares do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEditora (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais SEDEX)

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 30 de novembro: R$ 8,80)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

Para solicitar alguns títulos específicos:

Artigo1 "Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone"

Artigo2 "Moral e Economia"

Artigo3 "Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz"

Artigo4 "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada"

Próximos temas:

"Capitalismo, globalização, neoliberalismo, privatizações"

"Economia de Mercado, Neoliberalismo"

"Estatização da Economia"

LINK DE REMOÇÃO

ConstruNews:Remover dhc-archive@ietf.org

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 

 

From dhcwg-admin@ietf.org Sat Nov 15 12:49:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14042; Sat, 15 Nov 2003 12:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4Xd-0003Ft-RE; Sat, 15 Nov 2003 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4XF-0003FP-EN for dhcwg@optimus.ietf.org; Sat, 15 Nov 2003 12:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14015; Sat, 15 Nov 2003 12:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL4XB-0002ow-00; Sat, 15 Nov 2003 12:48:33 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AL4XA-0002ot-00; Sat, 15 Nov 2003 12:48:32 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAFHmLGn043955; Sat, 15 Nov 2003 12:48:31 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Tim Chown'" , , Subject: RE: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Date: Sat, 15 Nov 2003 12:48:23 -0500 Message-ID: <000001c3aba0$ade83820$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <20031114160645.GE19013@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable DHCPv6 is no different from what we have with DHCPv4. DHCPINFORM in = DHCPv4 has no "lease time" or "lifetime" for the parameters obtained. The = implied behavior for DHCPv4, as it should be for DHCPv6, is that when the = address is reassigned (through some other means), the client should naturally = assume that its current configuration parameters are suspect and hence send a = new DHCPINFORM (or DHCPv6 Information-Request). There is no prohibition against a client issuing (DHCPv6) Information-Request messages (or DHCPv4 DHCPINFORM) whenever it believes = the previously obtained configuration information may be out of date. Note = also that DHCPv6 servers may send Reconfigure messages as well (though draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless clients support this). When a client detects that it may be on a different network, whether = that is because it has detected a link state change (such as because the network cable was reconnected), been powered on (such as from a standby state), = or has its address(es) reconfigured through some non-DHCP mechanism = (perhaps via router advertisements), it should take steps to validate its configuration information. We probably should have added to RFC 3315 a similar section for Information-Request as exists for the stateful case (see section 18.1.2, Creation and Transmission of Confirm Messages). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Friday, November 14, 2003 11:07 AM To: dhcwg@ietf.org; iesg@ietf.org Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless = DHCPv6 Service' to Proposed Standard On Thu, Oct 30, 2003 at 05:57:10PM -0500, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG = to=20 > consider the following document: >=20 > - 'A Guide to Implementing Stateless DHCPv6 Service' > as a Proposed Standard Wrt recent exchanges on the dhcwg list, are we concerned that there is no mechanism in stateless DHCPv6 for the DHCPv6 server to inform DHCPv6 clients of renumbering events to DNS or NTP servers (for example) where the clients are using stateless autocinfiguration (RFC2462) for address assignment and DHCPv6 (stateless) for options (DNS, NTP, ...). If the clients use DHCPv6 for address assignment, the DHCPv6 server = could use its IP lease information to unicast the Reconfigure message, but in a stateless-only DHCPv6 server this client information would presumably not be available. The current solution seems to be that clients must poll for changes, = which is not ideal, but which may suffice in some cases. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Nov 15 14:35:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16172; Sat, 15 Nov 2003 14:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6CE-0007jv-SQ; Sat, 15 Nov 2003 14:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6Bm-0007jF-VB for dhcwg@optimus.ietf.org; Sat, 15 Nov 2003 14:34:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16116; Sat, 15 Nov 2003 14:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL6Bh-0003sR-00; Sat, 15 Nov 2003 14:34:29 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL6Bg-0003sM-00; Sat, 15 Nov 2003 14:34:28 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA15730; Sat, 15 Nov 2003 19:34:26 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA05286; Sat, 15 Nov 2003 19:34:26 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAFJYP602679; Sat, 15 Nov 2003 19:34:25 GMT Date: Sat, 15 Nov 2003 19:34:25 +0000 From: Tim Chown To: dhcwg@ietf.org, iesg@iesg.org Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Message-ID: <20031115193425.GA2471@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, iesg@iesg.org References: <20031114160645.GE19013@login.ecs.soton.ac.uk> <000001c3aba0$ade83820$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c3aba0$ade83820$6401a8c0@BVolz> User-Agent: Mutt/1.4i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Sat, Nov 15, 2003 at 12:48:23PM -0500, Bernie Volz wrote: > DHCPv6 is no different from what we have with DHCPv4. DHCPINFORM in DHCPv4 > has no "lease time" or "lifetime" for the parameters obtained. The implied > behavior for DHCPv4, as it should be for DHCPv6, is that when the address is > reassigned (through some other means), the client should naturally assume > that its current configuration parameters are suspect and hence send a new > DHCPINFORM (or DHCPv6 Information-Request). Hi Bernie, thanks for the comments. I think that in IPv6 we should be trying to incorporate aids to easy(er) renumbering, for a number of good reasons. Also in IPv6 networks it is now quite probable that many networks will statelessly autoconfigure addresses but use stateless DHCPv6 for options (DNS and NTP in particular). So it's a bit different to IPv4. > There is no prohibition against a client issuing (DHCPv6) > Information-Request messages (or DHCPv4 DHCPINFORM) whenever it believes the > previously obtained configuration information may be out of date. Note also > that DHCPv6 servers may send Reconfigure messages as well (though > draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless > clients support this). But this is the point - the DHCPv6 server can't send a Reconfigure message to the client, because the client is not using DHCPv6 for stateful address assignment, only for the DNS/NTP/other options (and so I believe the stateless DHCPv6 server won't have a client list to unicast the messages to?). There could at the very least be a timer for the valid lifetime of the stateless DHCPv6 options, so that planned ("make before break") renumbering as per draft-baker-ipv6-renumber-procedure-01 can be more readily achieved. That would not necessarily help with other renumbering events, but it would seem useful to have. > When a client detects that it may be on a different network, whether that is > because it has detected a link state change (such as because the network > cable was reconnected), been powered on (such as from a standby state), or > has its address(es) reconfigured through some non-DHCP mechanism (perhaps > via router advertisements), it should take steps to validate its > configuration information. I agree you could use a new RA (with O bit set) as a cue to get new DHCPv6 option information; this has also been suggested on the dhcwg list. But it wouldn't include the case where the DNS or NTP server is renumbered within the existing network. > We probably should have added to RFC 3315 a similar section for > Information-Request as exists for the stateful case (see section 18.1.2, > Creation and Transmission of Confirm Messages). I think anything we can add now to make IPv6 renumbering more easy to do (both compared to IPv4, and because of existing IPv6 limitations like having no PI address space) should be considered, including a method to deliver a stateless DHCPv6 Reconfigure message to clients. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 16 17:19:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09001; Sun, 16 Nov 2003 17:19:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALVET-00089g-Le; Sun, 16 Nov 2003 17:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALLCJ-0005NS-P1 for dhcwg@optimus.ietf.org; Sun, 16 Nov 2003 06:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25826 for ; Sun, 16 Nov 2003 06:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALLCF-0002B5-00 for dhcwg@ietf.org; Sun, 16 Nov 2003 06:36:03 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ALLCE-0002AO-00 for dhcwg@ietf.org; Sun, 16 Nov 2003 06:36: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 hAGBZQpI027789; Sun, 16 Nov 2003 12:35:27 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAGBZQR7002318; Sun, 16 Nov 2003 12:35:26 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAGBZOgA002317; Sun, 16 Nov 2003 12:35:24 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sun, 16 Nov 2003 12:35:24 +0100 From: Stig Venaas To: Masataka Ohta Cc: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031116113524.GB2256@sverresborg.uninett.no> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB40486.8020608@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB40486.8020608@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, Nov 14, 2003 at 07:24:06AM +0900, Masataka Ohta wrote: > >One option for passing the new DNS options from the DHCPv6 Light server > >to the client is a multicast Reconfigure message. That would work > >if the DHCPv6 Light server is on link, but if relays are used and there > >is no multicast routing on site, this seems to be a gap (and a case for > >the RA method - though of course with RA method you still need to > >reconfigure the router for the new RA...) I'll comment on your mail, but let me first present how I suggest it be done. I suggest for server to send reconfigure to clients via relays. From server to relay: If multicast routing available in the site: site scoped multicast from server to relays If multicast routing not available in the site: unicast to each relay, server has a list of relays Then from relay to client you can always use multicast on link. Reconfigure messages should be protected due to possible DoS attacks. I didn't consider that at first. I think that can be done using public key crypto. Server has a single key pair. Clients get public key together with the config info, and the reconfigure message is signed with the private key. Now to your comments. > W.r.t. inter-link multicast, what multicast protocols is intended > to be used by people in DHC WG? I'm not sure that should be specified. At least as long as it isn't SSM, the DHCP infrastructure is completely independent of which multicast protocols are used, just like other multicast applications. > If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes > or is renumbered? Interesting question. It's relatively easy with standard PIM-SM. You only need to reconfigure the RP address on the routers, and if you use say BSR, you only need to change on the c-BSRs and c-RPs. And only within the site. There are also ways to secure multicast against RP crashes etc. Discussion on multicast reliability and renumbering could be a good topic for mboned wg. It doesn't belong here. For SSM, relays would need to know unicast addresses of DHCP servers, and if you do reconfigure with multicast, you also need servers to know unicast addresses of relays. Then you might as well use unicast. > Is a well known unicast address is assigned to a primary and > a back-up CORE/RP/SS, which means ANYCAST. Anycast might be used > Is DVMRP assumed, instead? Nothing is assumed I think. > Or, will we wait until yet another multicast protocol is > standardized, hoping that it will solve all the problems? > > Assuming that some multicast protocol solves all the > problems, another question is on multicast address. I think multicast works pretty well, but this should rather be discussed in mboned. > Is it a well known multicast address? If so, is there any Yes > configuration necessary at a site (or something like that) > border router? If so, what happens if a customer want to relay > DHCP request to ISP's DHCP server? What happens the border > router is wrongly configured? Of course things can be wrongly configured, but most things can break then. If you want to relay DHCP requests out of the site, the best is to use unicast between relay and server I think, using site multicast is only an option. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 17 04:03:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05846; Mon, 17 Nov 2003 04:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALfHh-0006lk-01; Mon, 17 Nov 2003 04:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALfHW-0006lU-RN for dhcwg@optimus.ietf.org; Mon, 17 Nov 2003 04:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05838 for ; Mon, 17 Nov 2003 04:02:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALfHU-0003ft-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 04:02:48 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx with esmtp (Exim 4.12) id 1ALfHT-0003fq-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 04:02:47 -0500 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 2812133; Mon, 17 Nov 2003 10:02:46 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Date: Mon, 17 Nov 2003 10:05:11 +0100 User-Agent: KMail/1.4.3 References: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200311171005.11781.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Friday 31 October 2003 14.43, Ralph Droms wrote: > This message announces a WG last call on "DHCP Failover Protocol" > . The last call will conclude at 5PM E= T on > Monday, 11/17/2003. And lastly, we support advancing this draft to Proposed Standard. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 11:57:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00199; Tue, 18 Nov 2003 11:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM99x-0008UI-HF; Tue, 18 Nov 2003 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM99N-0008Tc-LG for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 11:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00128 for ; Tue, 18 Nov 2003 11:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM99M-0000k7-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 11:56:24 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AM99L-0000jw-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 11:56:23 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAIEmIm06252; Tue, 18 Nov 2003 15:48:19 +0100 Message-ID: <3FBA3132.8070408@it.su.se> Date: Tue, 18 Nov 2003 15:48:18 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Bernie Volz CC: "'Markus Schabel'" , dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP References: <000501c3a9fe$de985b60$6401a8c0@BVolz> In-Reply-To: <000501c3a9fe$de985b60$6401a8c0@BVolz> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernie Volz wrote: | There was some work done a while ago on this topic but it never was finished | and there has generally been a lack of interest to do it (at least in a | standardized way). One issue is that servers have very different | capabilities and therefore developing a standard limits functionality to the | "common" capabilities. There are some servers that do use LDAP or can store | information in LDAP, but I think they've generally used a proprietary | schema. | Imo that is not a correct analysis. Certainly there will be differences and proprietary solutions but that does not imply that there cannot be a standard information model common to all implementations. Good schema work in the ietf depends on a common view of the underlying information model. The draft referenced by Markus has *lots* of problems. I would be willing to help work on this but there needs to be a clear statement of interest from the wg. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/ujEy8Jx8FtbMZncRAndhAKCFFaOdJpY01d+7r6cPmgc8kNrbGQCgqWQC WPBr+vi5dmpw33pOV57tkNo= =Scxl -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 12:28:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02778; Tue, 18 Nov 2003 12:28:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9dw-0002i5-Pk; Tue, 18 Nov 2003 12:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9dh-0002hj-3Z for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 12:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02701 for ; Tue, 18 Nov 2003 12:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9dc-0001bo-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 12:27:40 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AM9db-0001bh-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 12:27:40 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAIHRUAr047750; Tue, 18 Nov 2003 12:27:39 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Leif Johansson'" Cc: "'Markus Schabel'" , Subject: RE: [dhcwg] LDAP Schema for DHCP Date: Tue, 18 Nov 2003 12:27:36 -0500 Message-ID: <000001c3adf9$45e9d480$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <3FBA3132.8070408@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable It all depends on what you want to use LDAP for. There's: - Configuration information for the server or service (whether = implemented in one or many servers). And, there's also the "current" vs. the "next" configuration to consider. - Active lease information (this is, IMO, the easiest to standardize = since it is well defined based on RFC 2131/2132). Such as what client is using = the address and which options were sent to it. - Historical lease information (what clients had what addresses when). And, there are probably other uses that I haven't mentioned. The Policy Framework WG has made very little progress in schemas - or, = put another way, it has taken many years to get where they are now and many revisions of the drafts. This is not an easy space - I spent several = years trying to work in it and finally gave up. And, admittedly I haven't = followed that WG for several years now. In addition, there are significant performance penalties paid by putting = too much into LDAP. For example, good luck being able to perform 1,000 = leases per second when using LDAP to store the active lease information. LDAP = was primarily designed for many reads, not many writes. At least, that was = my experience over the past 5 or so years. And putting configuration information into LDAP, while possible, = certainly constrains how information is represented. Lots of servers now have conditional expressions and the like, making the LDAP representation = more challenging. I have no issues if you folks want to try. Just be ready for a long and difficult road. And, personally, I'm not that interested. And, past = history has shown that there wasn't sufficient interest to make this go. - Bernie -----Original Message----- From: Leif Johansson [mailto:leifj@it.su.se]=20 Sent: Tuesday, November 18, 2003 9:48 AM To: Bernie Volz Cc: 'Markus Schabel'; dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernie Volz wrote: | There was some work done a while ago on this topic but it never was finished | and there has generally been a lack of interest to do it (at least in = a | standardized way). One issue is that servers have very different | capabilities and therefore developing a standard limits functionality to the | "common" capabilities. There are some servers that do use LDAP or can store | information in LDAP, but I think they've generally used a proprietary | schema. | Imo that is not a correct analysis. Certainly there will be differences and proprietary solutions but that does not imply that there cannot be a standard information model common to all implementations. Good schema work in the ietf depends on a common view of the underlying information model. The draft referenced by Markus has *lots* of problems. I would be willing to help work on this but there needs to be a clear statement of interest from the wg. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/ujEy8Jx8FtbMZncRAndhAKCFFaOdJpY01d+7r6cPmgc8kNrbGQCgqWQC WPBr+vi5dmpw33pOV57tkNo=3D =3DScxl -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 13:02:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04209; Tue, 18 Nov 2003 13:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAAr-0004f5-6X; Tue, 18 Nov 2003 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAAh-0004eu-Eb for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 13:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04197 for ; Tue, 18 Nov 2003 13:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAAf-0002Cz-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 13:01:49 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AMAAf-0002Cu-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 13:01:49 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAII1Gho293444; Tue, 18 Nov 2003 13:01:16 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAII1EWJ109036; Tue, 18 Nov 2003 13:01:15 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hAIHtCoA020484; Tue, 18 Nov 2003 12:55:12 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hAIHtCRE020479; Tue, 18 Nov 2003 12:55:12 -0500 Message-Id: <200311181755.hAIHtCRE020479@rotala.raleigh.ibm.com> To: dnsop@cafax.se, dhcwg@ietf.org In-Reply-To: Message from tjc@ecs.soton.ac.uk of "Thu, 13 Nov 2003 19:11:45 GMT." <20031113191145.GS3473@login.ecs.soton.ac.uk> Date: Tue, 18 Nov 2003 12:55:12 -0500 From: Thomas Narten Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Tim Chown writes: > With DHCPv6 Light for DNS option configuration, how is the client told > that DNS options have changed? The reconfigure message seems to be > unicast to the clients, but if the DHCPv6 server is stateless, it won't > have a list of clients (with leased IPs) to send that Reconfigure > message to? note that there are issues with unicast reconfigure. During the IESG review of the DHCv6 spec, concerns were raised about the appropriateness of _requiring_ that all nodes have an open port on which DHC messages could be sent. This is viewed as a security issue. E.g., for security reasons, some sites require that clients have no open ports on which they are listening for arbitrary packets from anyone. Consequently, the DHCPv6 spec was revised to make the use of this feature more of a negotiation between the client and server. See the RFC for details. Point is, requiring that a node always be ready to receive an asynchronous message from an arbitrary DHC server is potentially problematical in practice. Personally, I think something along the lines of Bernie's suggestion seems the simplest. E.g., just define a lifetime that applies to all options that don't themselves have a lifetime. Client can then recheck at appropriate intervals. "Bernie Volz" writes: > There was some discussion about adding a "configuration lifetime" option for > Information-Request/Reply messages. This would be similar to the address > lifetimes and the idea would be that this would give the client an > indication of when to obtain updated configuration information. While this > does not solve the problem completely, it would help solve the problem when > scheduled changes in the network are planned. > We may also want to have clients that initiate an Information-Request after > detecting a configuration change that may invalidate existing information > (such as prefixes in configuration information that are no longer valid) use > a random delay before sending the Information-Request (just as they would > for the 'first' Information-Request). Perhaps this just means clarifying > what is meant in section 18.1.5 (RFC 3115) by first: > The first Information-request message from the client on the > interface MUST be delayed by a random amount of time between 0 and > INF_MAX_DELAY. > There are also larger issues here when renumbering happens as the client may > need to its DNS information (dynamic DNS), etc. So, when renumbering happens > (new addresses are added or old ones are deprecated), the client needs to do > some thinking and one of the outcomes is to obtain updated configuration > information. > - Bernie > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Tim > Chown > Sent: Thursday, November 13, 2003 4:00 PM > To: SHIRASAKI Yasuhiro > Cc: dnsop@cafax.se; dhcwg@ietf.org > Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug? > > Both setting the trigger of re-request on renumbering of prefix in RA, > > and a multicast Reconfigure message might cause all nodes to rush on > > the single DHCPv6-lite server for information-request reply exchange. > > It could work with small number of clients though. > I guess you could add some random delays, but you should also scale your > DHCPv6 server provision to have multiple servers? > I guess we can say that: > (1) Automatic renumbering is broken if people hard-code data in clients > (2) If a secure environment for reconfigure is needed, a multicast message > adds some complexity > (3) The Reconfigure message is really designed for a fully stateful DHCPv6 > environment, not a purely stateless one providing options info (?) > (4) Periodic polling of the DHCPv6 server by clients allows renumbering > but is not a full solution for more rapid (unplanned) renumbering. > (5) There isn't really a ethod now for a client to be informed of a > renumbering event of a stateless DHCPv6 option (DNS, NTP) > (6) We don't want to use RA method because that would also mean an NTP > extension for RA (?) > (7) If the network renumbers, statelessly configuring hosts should/could > use the new prefix seen on an RA as a hint to re-request DHCPv6 > options if the O bit is set. > So is something overlooked, or do we not feel we need a solution to (5), > given we could use (7)? Not sure how explicit (7) is... > Tim > _______________________________________________ > 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-admin@ietf.org Tue Nov 18 17:41:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22384; Tue, 18 Nov 2003 17:41:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEWu-0006N7-Is; Tue, 18 Nov 2003 17:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEVw-0006Lz-JL for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 17:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22293 for ; Tue, 18 Nov 2003 17:39:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEVp-0001AU-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 17:39:57 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEVo-0001AL-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 17:39:56 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA17519; Tue, 18 Nov 2003 22:39:54 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA11364; Tue, 18 Nov 2003 22:39:53 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIMdrk32028; Tue, 18 Nov 2003 22:39:53 GMT Date: Tue, 18 Nov 2003 22:39:53 +0000 From: Tim Chown To: dnsop@cafax.se, dhcwg@ietf.org Message-ID: <20031118223953.GE31666@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se, dhcwg@ietf.org References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <200311181755.hAIHtCRE020479@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline In-Reply-To: <200311181755.hAIHtCRE020479@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4i Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 18, 2003 at 12:55:12PM -0500, Thomas Narten wrote: > > note that there are issues with unicast reconfigure. During the IESG > review of the DHCv6 spec, concerns were raised about the > appropriateness of _requiring_ that all nodes have an open port on > which DHC messages could be sent. This is viewed as a security > issue. E.g., for security reasons, some sites require that clients > have no open ports on which they are listening for arbitrary packets > from anyone. Consequently, the DHCPv6 spec was revised to make the use > of this feature more of a negotiation between the client and > server. See the RFC for details. There may be other methods to give the hint for a (RFC2462) client to send a new (options) request to the (stateless) DHCP server. This might involve something in an RA, some new form of Reconfigure message (although I can see this isn't favoured, it is specified for stateful servers to use), or some other method. > Personally, I think something along the lines of Bernie's suggestion > seems the simplest. E.g., just define a lifetime that applies to all > options that don't themselves have a lifetime. Client can then > recheck at appropriate intervals. A timer is an improvement; at least then the timer could be tuned down a bit like DNS TTL for a planned renumbering event, or for simpler events like adding a new NTP server or changing the DNS search path. Attached is a draft that I've just submitted describing the problem statement. Vijay and Stig are both working on proposals for solutions. It would be great to get your input on those based on the IESG discussion experience (for example on the security requirements). The problem/gap is a bit broader then just site renumbering, so the draft name is not ideal. Tim --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stateless-00.txt" Dynamic Host Congiguration T. Chown Internet-Draft University of Southampton Expires: May 18, 2004 S. Venaas UNINETT A.K. Vijayabhaskar Hewlett-Packard November 18, 2003 Renumbering Requirements for Stateless DHCPv6 draft-chown-dhc-stateless-dhcpv6-renumbering-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 18, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 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 Chown, et al. Expires May 18, 2004 [Page 1] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4 3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . . . 4 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4 5. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Chown, et al. Expires May 18, 2004 [Page 2] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 1. Introduction IPv6 hosts using Stateless Address Autoconfiguration [1] are able to automatically configure their IPv6 address and default router settings. While Stateless Address Autoconfiguration for IPv6 allows automatic configuration of these settings, it does not provide a mechanism for additional, non IP-address settings to be automatically configured. The full version of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [2] is designed to provide both stateful address assignment to IPv6 hosts, as well as additional (non IP-address) configuration including DNS, NTP and other specific settings. A full stateful DHCPv6 server allocates the addresses and maintains the clients bindings to keep track of client leases. If hosts using Stateless Address Autoconfiguration for IPv6 wish to automatically configure their DNS, NTP or other specific settings the stateless variant [3] of DHCPv6 could be used. The stateless variant of DHCPv6 is more lightweight. It does not do address assignment, instead it only provides additional configuration parameters like DNS resolver addresses. It does not maintain state about the information assigned to clients; the additional parameters do not have an explicit life-time associated with them in the same way that IP addresses do, and hence the DHCPv6 server does not need to maintain the state of the clients. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. In the absence of an alternative method for DNS, NTP and other options to be automatically configured, it may become the most common combination for statelessly configuring hosts. 2. Problem Statement A problem however lies in the ability, or lack of ability, of clients using this combination to be informed of (or to deduce) changes in DHCPv6 assigned settings. While a DHCPv6 server unicasts Reconfigure message to individual clients to trigger the clients to intiate Information-request/reply configuration exchanges to update their configuration settings, the stateless variant of DHCPv6 cannot use the Reconfigure mechanism because it does not maintain a list of IP addresses (leases) to send the unicast messages to. Thus events including the following cannot be handled: Chown, et al. Expires May 18, 2004 [Page 3] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 o Full site renumbering o DNS server change of address o NTP server change of address o Changes in DNS search paths It would be highly desirable that a host using the combination of Stateless Address Autoconfiguration and stateless DHCPv6 could handle a renumbering or reconfiguration event, whether planned or unplanned by the network administrator. 3. Renumbering Scenarios There are two main scenarios for changes to DHCPv6-assigned settings, that would require the client to initiate an Information-request/ reply exchange to update the configuration. 3.1 Site renumbering One of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider assigned (PA) address space. There is currently no provider independent (PI) address space in IPv6. A site wishing to change ISP must thus renumber its network. Any such site renumbering will require hosts to reconfigure both their own address and default router settings as well as their stateless DHCPv6-assigned settings. 3.2 Changes to a DHCPv6-assigned setting An administrator may need to change one or more stateless DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS search path. This may be required if a new, additional DNS server is brought online, is moved to a new network (prefix), or an existing server is decommissioned or known to be unavailable. 4. Renumbering Requirements Ideally, any of the above scenarios should be handled automatically by the hosts on the network. For this to be realised, a method is required for the hosts to be informed that they should request new stateless DHCPv6-assigned setting information. The solution to the problem may depend on whether the renumbering or configuration change is a planned or unplanned one, from the perspective of the network administrator. There is already work underway in understanding the planned renumbering [4] scenario for Chown, et al. Expires May 18, 2004 [Page 4] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 IPv6 networks. However, there is currently no mechanism in stateless DHCPv6 to even handle planned renumbering events. The unplanned renumbering event, which may be more common in smaller, unmanaged networks, is more difficult to cater for. Ideally, any solution for the problem should consider planned and unplanned events. The solution should also be secure, such that additional security concerns are not added to the stateless DHCPv6 networking environment. 5. Solution Space Solutions should be designed and presented in a separate document. An initial, brief set of candidate solutions might include: o Adding a Reconfigure message mechanism that would work in the stateless DHCPv6 environment. This could enable planned or unplanned events, but may require a multicast mechanism to be realised. o Conveying a valid lifetime timer to clients for stateless DHCPv6-assigned settings. This could primarily enable planned events, but with a small time-out it could to some extent handle unplanned events at the expense of the additional request traffic. o Using some form of Router Advertisement as a hint to request new stateless DHCPv6-assigned settings. Using only an observed new Router Advertisement prefix as a hint to re-request settings would not handle changes that are purely to NTP, DNS or other options. 6. Summary This document presents a problem statement for how IPv6 hosts that use the combination of Stateless Address Autoconfiguration and stateless DHCPv6 may be informed of renumbering events or other changes to the settings that they originally learnt through stateless DHCPv6. A short list of candidate solutions is presented, which the authors hope may be expanded upon in subsequent documents. 7. Security Considerations There are no security considerations in this problem statemement per se. However, whatever mechanism is designed or chosen to address this problem should avoid the introduction of new security concerns for (stateless) DHCPv6. Chown, et al. Expires May 18, 2004 [Page 5] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 Normative References [1] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 2003. [4] Baker, F., "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in progress), October 2003. Authors' Addresses Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Stig Venaas UNINETT Trondheim NO 7465 Norway EMail: venaas@uninett.no Vijayabhaskar A K Hewlett-Packard STSD-I 29, Cunningham Road Bangalore 560052 India EMail: vijayak@india.hp.com Chown, et al. Expires May 18, 2004 [Page 6] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Chown, et al. Expires May 18, 2004 [Page 7] Internet-Draft Renumbering for Stateless DHCPv6 November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chown, et al. Expires May 18, 2004 [Page 8] --+g7M9IMkV8truYOl-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 17:43:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22535; Tue, 18 Nov 2003 17:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEYm-0006aK-VJ; Tue, 18 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEYa-0006Z4-Cf for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 17:42:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22473 for ; Tue, 18 Nov 2003 17:42:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEYU-0001FZ-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 17:42:42 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AMEYT-0001FQ-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 17:42:41 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAJ0eZm09811; Wed, 19 Nov 2003 01:40:35 +0100 Message-ID: <3FBABC03.2010102@it.su.se> Date: Wed, 19 Nov 2003 01:40:35 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Bernie Volz CC: "'Markus Schabel'" , dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP References: <000001c3adf9$45e9d480$6401a8c0@BVolz> In-Reply-To: <000001c3adf9$45e9d480$6401a8c0@BVolz> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | | The Policy Framework WG has made very little progress in schemas - or, put | another way, it has taken many years to get where they are now and many | revisions of the drafts. This is not an easy space - I spent several years | trying to work in it and finally gave up. And, admittedly I haven't followed | that WG for several years now. | That is another way of saying their schemas are broken, a view shared by many in ldap space. There are technical reasons for that (as other schema-geeks could tell you), but the bottom line is that the schemas are too complex by far. | In addition, there are significant performance penalties paid by putting too | much into LDAP. For example, good luck being able to perform 1,000 leases | per second when using LDAP to store the active lease information. LDAP was | primarily designed for many reads, not many writes. At least, that was my | experience over the past 5 or so years. | That is a myth. It all depends on the implementation. There is no law which states that just because a service exposes an LDAP interface it must be implemented as a traditional general-purpose directory server. It is just bits on the wire together with an information model! In most cases where (and lease-info is such a case imo) the schema has little or no relation with traditional white-pages data (persons, groups etc) this type of implementation is relatively easy to do (because there is no problem exposing the data in a separate tree). For a server it would entail implementing a small subset of core ldap in the server event- loop for read-only operations which in itself is a relatively trivial exercise given the right marshalling tools. | And putting configuration information into LDAP, while possible, certainly | constrains how information is represented. Lots of servers now have | conditional expressions and the like, making the LDAP representation more | challenging. Certainly one must be careful. Never try to implement general policy in a directory but often it is not necesary. I still think it might be useful to represent a *subset* of the general information model where it coincides with widely deployed schema representing hosts and groups of hosts. This would benefit sites which have large directory driven host-management systems. You are quite right that before anyone tries to write schema we must identify the use-cases correctly. Lease-information is a valid use- case and I suspect that the performance issue isn't one. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/urwC8Jx8FtbMZncRAiPyAKCxlWekIuQAJ+EV03BVm/0uPBXRDgCdHyq/ FPQ6kFJYB5MIq+ej7DPBIAA= =J9rC -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 19:27:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27465; Tue, 18 Nov 2003 19:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGBT-0003oX-81; Tue, 18 Nov 2003 19:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBLI-00018L-UC for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 14:16:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07828 for ; Tue, 18 Nov 2003 14:16:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMBLG-0003YU-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 14:16:50 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1AMBLF-0003YQ-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 14:16:49 -0500 Received: from sip (pD9587661.dip.t-dialin.net [217.88.118.97]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hAIJGb01000349; Tue, 18 Nov 2003 20:16:37 +0100 (MET) From: "Christian Stredicke" To: Cc: "'Henry Sinnreich'" , "'Henning Schulzrinne'" , "'Wilhelm Wimmreuter'" , "'Rentschler, Markus'" Date: Tue, 18 Nov 2003 20:17:34 +0100 Message-ID: <019601c3ae08$9f9af590$6401a8c0@sip> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01C3AE11.015F5D90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [dhcwg] Comments on draft-rentschler-dhc-discovery-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0197_01C3AE11.015F5D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there! We found Markus' draft after a discussion in the SIP area. The problem that we have is to tell a SIP user agent (which is typically a voice over IP phone according to RFC3261) that the access to the Internet has changed (for example, the ISP has changed the IP address) or has been rebooted. In the case of an IP address change, the client must reregister as soon as possible in order to stay reachable from the outside world. In the case of a reboot it is helpful to restore the state in a possibly present application layer gateway in the Internet access device. To me this looks like a problem that potentially other applications (for example, online gaming) also have. Therefore I think it makes sense to use a standard out of the scope of SIP to solve this problem. Practically, DHCP is used in these networks and to me it seems only natural to use the DHCP to solve our problem. Therefore, I support the draft written by Markus. For the problem that we see it would solve the problem in an easy and efficient way. Please continue the good work in this area! Thanks, Christian -- Christian Stredicke tel:+49.30.39833.401 (ENUM & PSTN) ------=_NextPart_000_0197_01C3AE11.015F5D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

 

We found Markus’ draft after a = discussion in the SIP area. The problem that we have is to tell a SIP user agent = (which is typically a voice over IP phone according to RFC3261) that the access to = the Internet has changed (for example, the ISP has changed the IP address) = or has been rebooted. In the case of an IP address change, the client must = reregister as soon as possible in order to stay reachable from the outside world. = In the case of a reboot it is helpful to restore the state in a possibly = present application layer gateway in the Internet access = device.

 

To me this looks like a problem that = potentially other applications (for example, online gaming) also have. Therefore I = think it makes sense to use a standard out of the scope of SIP to solve this = problem. Practically, DHCP is used in these networks and to me it seems only natural to use = the DHCP to solve our problem.

 

Therefore, I support the draft written by = Markus. For the problem that we see it would solve the problem in an easy and = efficient way. Please continue the good work in this area!

 

Thanks, Christian

--

Christian Stredicke

tel:+49.30.39833.401 (ENUM & = PSTN)

------=_NextPart_000_0197_01C3AE11.015F5D90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 19:43:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28136; Tue, 18 Nov 2003 19:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGQu-0004tU-Kp; Tue, 18 Nov 2003 19:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGQY-0004se-IR for dhcwg@optimus.ietf.org; Tue, 18 Nov 2003 19:42:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28101 for ; Tue, 18 Nov 2003 19:42:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMGQW-0003yv-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 19:42:36 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AMGQV-0003ys-00 for dhcwg@ietf.org; Tue, 18 Nov 2003 19:42:36 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAJ0fIAr042106; Tue, 18 Nov 2003 19:41:29 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Tim Chown'" , "'Ralph Droms'" Cc: Subject: RE: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Date: Tue, 18 Nov 2003 19:41:25 -0500 Message-ID: <000001c3ae35$e0eddad0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <20031118223953.GE31666@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Tim/Ralph: Personally, I'd prefer we take two approaches to address these problems (text taken from Tim's document, section 5): o Conveying a valid lifetime timer to clients for stateless DHCPv6-assigned settings. This could primarily enable planned events, but with a small time-out it could to some extent handle unplanned events at the expense of the additional request traffic. o Using some form of Router Advertisement as a hint to request new stateless DHCPv6-assigned settings. Using only an observed new Router Advertisement prefix as a hint to re-request settings would not handle changes that are purely to NTP, DNS or other options. The first handles planned changes. The second handles renumbering. For = the second case, the client SHOULD send an Information-Request when any = prefix for an address conveyed in the last Reply transitions from a) preferred = to valid (i.e., preferred lifetime expires) or b) is no longer valid (i.e., valid lifetime expires). [I'm not certain how easy this is to implement = in most operating systems, but periodic polls by the DHCP Client can = probably discover these changes within reasonable time periods. Note that care = must be taken for the client not to consider prefixes it knows nothing = about.] There is no mechanism to address unplanned changes (such as changing a = DNS server's address as discussed in 3.2). But, that's where redundancy = comes in - by having multiple servers a client can contact, this problem can be minimized (until the "valid lifetime timer" expires). This IS covered by = a client (and server) supporting Reconfigure in the Information-Request = case - RFC 3315 does not prohibit this in an Information-Request (and Appendix = A shows it is allowed). So, in essence, all THREE of Tim's Section 5 = possible solutions are available. It would be optional, because as Thomas = indicated there are security concerns for forcing a client to listen for = unsolicited traffic (and a server may also choose not to support it). So what actions are needed? 1. Someone needs to publish a "valid lifetime" draft. Tim, are you = planning on doing this? Ralph? 2. Words should be added to draft-ietf-dhc-dhcpv6-stateless-01.txt to recommend (SHOULD?) that clients use certain events to trigger resending Information-Requests (see above and also the triggers for sending = Confirm messages in RFC 3315?). 3. Perhaps the stateless draft should also add words to the effect that supporting Reconfigure has advantages. Personally, this is where my view = of what draft-ietf-dhc-dhcpv6-stateless-*.txt should discuss and what it = does differ. I don't feel it should say that DHCP servers and clients are stateless, just what is required when DHCP is NOT used for address allocation (because stateless address configuration is being used in the network). I believe this ONLY impacts text in the Abstract and section = 1, Introduction, of draft-ietf-dhc-dhcpv6-stateless-01.txt. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Tuesday, November 18, 2003 5:40 PM To: dnsop@cafax.se; dhcwg@ietf.org Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? On Tue, Nov 18, 2003 at 12:55:12PM -0500, Thomas Narten wrote: >=20 > note that there are issues with unicast reconfigure. During the IESG > review of the DHCv6 spec, concerns were raised about the > appropriateness of _requiring_ that all nodes have an open port on > which DHC messages could be sent. This is viewed as a security > issue. E.g., for security reasons, some sites require that clients > have no open ports on which they are listening for arbitrary packets > from anyone. Consequently, the DHCPv6 spec was revised to make the use > of this feature more of a negotiation between the client and > server. See the RFC for details. There may be other methods to give the hint for a (RFC2462) client to = send=20 a new (options) request to the (stateless) DHCP server. This might = involve something in an RA, some new form of Reconfigure message (although I can = see this isn't favoured, it is specified for stateful servers to use), or = some other method. > Personally, I think something along the lines of Bernie's suggestion > seems the simplest. E.g., just define a lifetime that applies to all > options that don't themselves have a lifetime. Client can then > recheck at appropriate intervals. A timer is an improvement; at least then the timer could be tuned down a bit like DNS TTL for a planned renumbering event, or for simpler events like adding a new NTP server or changing the DNS search path. Attached is a draft that I've just submitted describing the problem statement. Vijay and Stig are both working on proposals for solutions. It would be great to get your input on those based on the IESG = discussion experience (for example on the security requirements). The problem/gap is a bit broader then just site renumbering, so the = draft name is not ideal. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 20:12:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27464; Tue, 18 Nov 2003 19:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGBS-0003oC-8v; Tue, 18 Nov 2003 19:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlig-0005ca-Qz for dhcwg@optimus.ietf.org; Mon, 17 Nov 2003 10:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17007 for ; Mon, 17 Nov 2003 10:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlie-0000Rz-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 10:55:16 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1ALlic-0000Rw-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 10:55:15 -0500 Received: (qmail 86124 invoked from network); 17 Nov 2003 16:04:07 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 17 Nov 2003 16:04:07 -0000 Message-ID: <3FB8EFCD.9080008@necom830.hpcl.titech.ac.jp> Date: Tue, 18 Nov 2003 00:57:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Stig Venaas CC: Tim Chown , dnsop@cafax.se, dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB40486.8020608@necom830.hpcl.titech.ac.jp> <20031116113524.GB2256@sverresborg.uninett.no> In-Reply-To: <20031116113524.GB2256@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stig; >>>One option for passing the new DNS options from the DHCPv6 Light server >>>to the client is a multicast Reconfigure message. That would work >>>if the DHCPv6 Light server is on link, but if relays are used and there >>>is no multicast routing on site, this seems to be a gap (and a case for >>>the RA method - though of course with RA method you still need to >>>reconfigure the router for the new RA...) > I'll comment on your mail, but let me first present how I suggest > it be done. Thanks. > I suggest for server to send reconfigure to clients via relays. > >>From server to relay: > > If multicast routing available in the site: "site" is not a useful concept for autoconfiguration, when the "site" is really small, which is, perhaps, the primary target case of "stateless", which is why I asked multicast over site boundaries. Note also that "site" local unicast addresses are to be deprecated. Moreover, multicast is unreliable unless the server have a list of relays, unless unicast ACK is returned from each relay. And, then, use of multicast reduces the number of traffic by half (ignoring frequent multicast control traffic some are broadcast over a domain), which is not essential. So, > If multicast routing not available in the site: > > unicast to each relay, server has a list of relays is a rational approach for either case. Of course, the server have a stable storage. However, some says "has a list of relays" is a "stateful" approach and is no good. Lack of well definedness of "stateless" is making design and discussion very hard. > Then from relay to client you can always use multicast on link. It is unreliable that relays also should have lists of clients and stable storages or the server directly take care of the clients, in either of which case, unicast is good enough. > Reconfigure messages should be protected due to possible DoS > attacks. I didn't consider that at first. I think that can be > done using public key crypto. Server has a single key pair. > Clients get public key together with the config info, and the > reconfigure message is signed with the private key. Sorry, public key crypto is computationary expensive that it rather amplifies than prevents DoS effect. With your case, reconfigure messages with bogus signature will force clients perform expensive public key crypto computation. >>W.r.t. inter-link multicast, what multicast protocols is intended >>to be used by people in DHC WG? > I'm not sure that should be specified. At least as long as it > isn't SSM, the DHCP infrastructure is completely independent > of which multicast protocols are used, just like other > multicast applications. I asked not "specified" but "intended". When we want to analyse specific application, we must take into account all the layers to calculate number of packets, periods of delay, redundancy, security etc. >>If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes >>or is renumbered? > Interesting question. It's relatively easy with standard > PIM-SM. You only need to reconfigure the RP address on the > routers, and if you use say BSR, you only need to change on > the c-BSRs and c-RPs. It is more straight forward to change addresses of a DHCP server on relayes to be used for unicast relaying. However, a DHCP server is a single point of failure. > And only within the site. "site" is not a good idea. > There are > also ways to secure multicast against RP crashes etc. This type of approach improve reliability for certain types of failure but does not improve or rather disimprove reliability for other types. > Discussion on multicast reliability and renumbering could be > a good topic for mboned wg. It doesn't belong here. I'm afraid it is not an attractive idea to involve yet another WG in the thread. > For SSM, relays would need to know unicast addresses of DHCP > servers, and if you do reconfigure with multicast, you also > need servers to know unicast addresses of relays. Then you > might as well use unicast. Yup. But, is it "stateless"? >>Is a well known unicast address is assigned to a primary and >>a back-up CORE/RP/SS, which means ANYCAST. > Anycast might be used An interesting fact is that there are someone who don't want to use "anycast" for DNS servers, because it intermingles DNS and routing system. However DNS servers by DHCP with multicast is already eaqually bad. Then, are we having DHCP with multicast with anycast CORE/RP/SS? >>Or, will we wait until yet another multicast protocol is >>standardized, hoping that it will solve all the problems? >> >>Assuming that some multicast protocol solves all the >>problems, another question is on multicast address. > I think multicast works pretty well, but this should rather > be discussed in mboned. Sure. However, mboned is the worst place to discuss "multicast does not work at all". >>Is it a well known multicast address? If so, is there any > > > Yes > > >>configuration necessary at a site (or something like that) >>border router? If so, what happens if a customer want to relay >>DHCP request to ISP's DHCP server? What happens the border >>router is wrongly configured? > > > Of course things can be wrongly configured, but most things > can break then. Yes. My intention here is to demonstrate that, with multicast, routing and DHCP are intermingled. > If you want to relay DHCP requests out of the > site, the best is to use unicast between relay and server I > think, using site multicast is only an option. And, multicast is not a useful option, which means we need something for redundancy. Masataka Ohta _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 18 20:12:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27466; Tue, 18 Nov 2003 19:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGBS-0003oK-Ly; Tue, 18 Nov 2003 19:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALs9B-0004Yg-So for dhcwg@optimus.ietf.org; Mon, 17 Nov 2003 17:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10858 for ; Mon, 17 Nov 2003 17:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALs99-0000cT-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 17:47:03 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1ALs98-0000bC-00 for dhcwg@ietf.org; Mon, 17 Nov 2003 17:47:02 -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 hAHMkOpI019732; Mon, 17 Nov 2003 23:46:24 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAHMkOR7004984; Mon, 17 Nov 2003 23:46:24 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAHMkNdP004983; Mon, 17 Nov 2003 23:46:23 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 17 Nov 2003 23:46:23 +0100 From: Stig Venaas To: Masataka Ohta Cc: Tim Chown , dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031117224623.GC4875@sverresborg.uninett.no> References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB40486.8020608@necom830.hpcl.titech.ac.jp> <20031116113524.GB2256@sverresborg.uninett.no> <3FB8EFCD.9080008@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB8EFCD.9080008@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Nov 18, 2003 at 12:57:01AM +0900, Masataka Ohta wrote: > >I suggest for server to send reconfigure to clients via relays. After some thinking I see that this is much harder than I first anticipated (like always...). I'm still thinking about it, but it's not easy. > >>From server to relay: > > > > If multicast routing available in the site: > > "site" is not a useful concept for autoconfiguration, when > the "site" is really small, which is, perhaps, the primary > target case of "stateless", which is why I asked multicast > over site boundaries. Yes, I also see cases where it wouldn't work. Unicast to relays have advantages, also wrt to security. Only issue is that server will need to know their addresses. > > unicast to each relay, server has a list of relays > > is a rational approach for either case. I may agree. I'm trying to think of good ways to do reconfigure. For now I think I'll do more thinking of that before I go into possible solutions. As I said above it seems to be rather complex. > Of course, the server have a stable storage. > > However, some says "has a list of relays" is a "stateful" > approach and is no good. Yes, my feeling too. > Lack of well definedness of "stateless" is making design and > discussion very hard. Yes. I would say that the DHCP server has configuration state, but no dynamic state. A static list of relays is not ideal, but might be ok. There are levels of dynamic state too though, it should be avoided, but I feel the most essential is to not require state through restarts/reboots. If reconfigure requires state, it may be better to forget it. > >Then from relay to client you can always use multicast on link. > > It is unreliable that relays also should have lists of clients > and stable storages or the server directly take care of the > clients, in either of which case, unicast is good enough. Yes, relays should not have lists of clients. I'm not insisting on multicast in itself, but multicast is the only way I see to avoid having per client state. > >Reconfigure messages should be protected due to possible DoS > >attacks. I didn't consider that at first. I think that can be > >done using public key crypto. Server has a single key pair. > >Clients get public key together with the config info, and the > >reconfigure message is signed with the private key. > > Sorry, public key crypto is computationary expensive that it > rather amplifies than prevents DoS effect. Yes, that is a good point. > With your case, reconfigure messages with bogus signature will > force clients perform expensive public key crypto computation. Yes. It can avoid DoS attack on DHCP server (because all clients do reconfigure), but it puts a big burden on clients. This is a problem. > >>W.r.t. inter-link multicast, what multicast protocols is intended > >>to be used by people in DHC WG? > > >I'm not sure that should be specified. At least as long as it > >isn't SSM, the DHCP infrastructure is completely independent > >of which multicast protocols are used, just like other > >multicast applications. > > I asked not "specified" but "intended". I can't speak for people's intentions, but I don't expect people to have given it much thought. I may be wrong. But SSM will not work with current spec. Current spec allows site multicast to be used, but doesn't require it. So I would say it's up to the implementor and administrator. > >Interesting question. It's relatively easy with standard > >PIM-SM. You only need to reconfigure the RP address on the > >routers, and if you use say BSR, you only need to change on > >the c-BSRs and c-RPs. > > It is more straight forward to change addresses of a DHCP server > on relayes to be used for unicast relaying. However, a DHCP server > is a single point of failure. I don't agree on this. And if you have multicast deployed, you will make sure that works as well. > >Discussion on multicast reliability and renumbering could be > >a good topic for mboned wg. It doesn't belong here. > > I'm afraid it is not an attractive idea to involve yet another > WG in the thread. I agree, and I'm removing dnsop from this one. I don't think they are interested in these details. But if you want to discuss multicast and renumbering in general, you could if you like create a new thread on mboned and not mention DHCP. Well, just a suggestion. My point is that discussions on that problem is much better in that group. There is more expertise there, and I'm not sure how interested people are in dhc... > >For SSM, relays would need to know unicast addresses of DHCP > >servers, and if you do reconfigure with multicast, you also > >need servers to know unicast addresses of relays. Then you > >might as well use unicast. > > Yup. But, is it "stateless"? Not sure, I would like to avoid it though. It for sure adds complexity to implementation. > >>Is a well known unicast address is assigned to a primary and > >>a back-up CORE/RP/SS, which means ANYCAST. > > >Anycast might be used > > An interesting fact is that there are someone who don't want to > use "anycast" for DNS servers, because it intermingles DNS and > routing system. However DNS servers by DHCP with multicast is > already eaqually bad. Then, are we having DHCP with multicast > with anycast CORE/RP/SS? I'm not too sure about using anycast myself. But if you use anycast for RP, that's limited to the network. But let's not discuss how to make multicast reliable here. > Sure. However, mboned is the worst place to discuss "multicast > does not work at all". Well yes, people may not like it (; But there are people there that think that multicast could be improved. And I'm not sure renumbering has been given much thought. > My intention here is to demonstrate that, with multicast, routing > and DHCP are intermingled. I would say that multicast and routing is in the network, while DHCP is an application making use of multicast and routing. DHCP may use site-scoped multicast if available, but it's not required. However link-local multicast is required for IPv6 in general, also DHCP. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 03:00:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07797; Wed, 19 Nov 2003 03:00:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNFq-0001TG-F8; Wed, 19 Nov 2003 03:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNFB-0001Qb-Rv for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 02:59:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07760 for ; Wed, 19 Nov 2003 02:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMNF7-0002Ux-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 02:59:17 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1AMNF6-0002Uu-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 02:59:17 -0500 Received: (qmail 93452 invoked from network); 19 Nov 2003 08:08:43 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 19 Nov 2003 08:08:43 -0000 Message-ID: <3FBB2346.3040005@necom830.hpcl.titech.ac.jp> Date: Wed, 19 Nov 2003 17:01:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Stig Venaas CC: Tim Chown , dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? References: <20031113191145.GS3473@login.ecs.soton.ac.uk> <3FB40486.8020608@necom830.hpcl.titech.ac.jp> <20031116113524.GB2256@sverresborg.uninett.no> <3FB8EFCD.9080008@necom830.hpcl.titech.ac.jp> <20031117224623.GC4875@sverresborg.uninett.no> In-Reply-To: <20031117224623.GC4875@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stig; > Yes, I also see cases where it wouldn't work. Unicast to relays > have advantages, also wrt to security. Only issue is that server > will need to know their addresses. > Yes, relays should not have lists of clients. I'm not insisting > on multicast in itself, but multicast is the only way I see to > avoid having per client state. Even if you use multicast, the addresses are necessary, anyway, to confirm receipt of notification. >>>Interesting question. It's relatively easy with standard >>>PIM-SM. You only need to reconfigure the RP address on the >>>routers, and if you use say BSR, you only need to change on >>>the c-BSRs and c-RPs. >> >>It is more straight forward to change addresses of a DHCP server >>on relayes to be used for unicast relaying. However, a DHCP server >>is a single point of failure. > I don't agree on this. And if you have multicast deployed, you > will make sure that works as well. BSR assumes that all the routers cooperate, which is not a case when an ISP and its subscribers constitute a domain. There are maliciousy or wrongly configured routers at subscribers. It should also be noted that an RP with forwarding functionaliry disabled may still announce its precense as an RP to a BSR, which means there is no real robustness. Intradomain multicast has its own area of application. However, the area is a lot smaller than one might expect and does not contain real robustness. Other protocols should not simply expect the area satisfies its requirement. > But let's not > discuss how to make multicast reliable here. Just accept that it is not reliable. >>Sure. However, mboned is the worst place to discuss "multicast >>does not work at all". > Well yes, people may not like it (; But there are people there > that think that multicast could be improved. That is the problem. When I overturned their grand design on interdomain multicast by proving that multicast routing table can not be aggregated (distribution of receivers of adjacent TV channels is no identical, so are of those of adjacent multicast addresses. See my paper presented at INET'98 for furthere details), such people tried to (and still trying, perhaps) *IMPROVE* multicast to make the impossible possible. > I would say that multicast and routing is in the network, while > DHCP is an application making use of multicast and routing. > DHCP may use site-scoped multicast if available, but it's not > required. It is required that all relay implimentations have code supporting multicast, because no server addresses may be configured. Do you recognize that control traffic of interlink multicast is often a lot lot more than that of applications like DHCP? > However link-local multicast is required for IPv6 in > general, also DHCP. Link local multicast is a lot simper than interlink ones and just works. Howvever, it works because broadcast works and broadcast is just enough. Note, for example, that there is no IGMP snooping on link local multicast that packets are broadcast to the entire link. So, there is the amount of link bandwidht is same. So, don't expect multicast too much. Instead, I think it is necessary for DHCP WG to develop guideline on robust relaying without relying on multicast. For example, is the behaviour of relay with multiple unicast addresses of servers specified somewhere? Masataka Ohta _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 08:30:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15869; Wed, 19 Nov 2003 08:30:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSPC-00016V-D5; Wed, 19 Nov 2003 08:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSOt-00015e-Df for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 08:29:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15852 for ; Wed, 19 Nov 2003 08:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSOq-0006tY-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 08:29:40 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AMSOp-0006tG-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 08:29:40 -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 hAJDSrpI016191; Wed, 19 Nov 2003 14:28:53 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAJDSrR7009555; Wed, 19 Nov 2003 14:28:53 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAJDSqxP009554; Wed, 19 Nov 2003 14:28:52 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Nov 2003 14:28:52 +0100 From: Stig Venaas To: Bernie Volz Cc: "'Tim Chown'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031119132852.GD9257@sverresborg.uninett.no> References: <20031118223953.GE31666@login.ecs.soton.ac.uk> <000001c3ae35$e0eddad0$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <000001c3ae35$e0eddad0$6401a8c0@BVolz> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've now submitted the draft draft-venaas-dhc-lifetime-00.txt on a lifetime timer. Which is one of the options in Tim's document. I also think this is one of the better approaches. Draft is attached. On Tue, Nov 18, 2003 at 07:41:25PM -0500, Bernie Volz wrote: [...] > So what actions are needed? > > 1. Someone needs to publish a "valid lifetime" draft. Tim, are you planning > on doing this? Ralph? [...] So this is done (: I have some open questions. What should client do if it can't update the configured data. I strongly feel it should keep it and retry. But how often. Can it be a function of the lifetime, or would we need an additional value? When should client add it to the option request list and when should server put it in replies. I have some SHOULD/MAY text which may need to be changed. The usage should be pretty clear. In unstable environments the value can be set to a small value. If a renumbering or other changes are planned, the administrator can gradually decrease the value, similar to DNS and ttls. Hope for some discussion on this and related topics. Stig --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-venaas-dhc-lifetime-00.txt" Internet Engineering Task Force S. Venaas Internet Draft UNINETT Expiration Date: May 2004 November 2003 Lifetime Option for DHCPv6 draft-venaas-dhc-lifetime-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes an option for specifying lifetime of other configuration options. It's mainly intended for the stateless DHCP, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server and update its configuration. Venaas [Expires May 2004] [Page 1] Internet Draft draft-venaas-dhc-lifetime-00.txt November 2003 Table of Contents 1. Introduction ............................................... 2 2. Terminology ................................................ 2 3. Lifetime option definition ................................. 3 4. IANA Considerations ........................................ 3 5. Acknowledgments ............................................ 3 6. Security Considerations .................................... 3 7. References ................................................. 4 7.1. Normative References ................................... 4 Author's Address ............................................... 4 1. Introduction For IPv6, many hosts will use stateless autoconfiguration as specified in [RFC 2462] for address assignment, and use DHCP [RFC 3315] for other configuration data. This other configuration data will typically have no associated lifetime, hence there may be no information telling a host when to update its DHCP configuration data. The option specified here tells the host the lifetime of the configuration data. When the lifetime expires, the host should make a new DHCP request, updating the current configuration. This request will usually be an Information-request Message. If the host fails to update the information, it should keep the current configuration, and retry at regular intervals. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC 2119]. Venaas [Expires May 2004] [Page 2] Internet Draft draft-venaas-dhc-lifetime-00.txt November 2003 3. Lifetime option definition A client supporting this option SHOULD include it in the Option Request option when sending an Information-request message to the DHCP server. A server supporting this option SHOULD include the option when requested by the client, but MAY also add it if not. The format of the Lifetime option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_LIFETIME | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_LIFETIME (to be decided) option-len: 4 lifetime: lifetime in seconds 4. IANA Considerations IANA is requested to assign an option-code for the lifetime option from the option-code space defined in [RFC 3315]. 5. Acknowledgments The author thanks Tim Chown and A.K. Vijayabhaskar for valuable discussions. 6. Security Considerations This option is believed not to have any impact on security. Venaas [Expires May 2004] [Page 3] Internet Draft draft-venaas-dhc-lifetime-00.txt November 2003 7. References 7.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2462] S. Thomson, T. Narten., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Author's Address Stig Venaas UNINETT NO-7465 Trondheim, Norway Email: venaas@uninett.no Venaas [Expires May 2004] [Page 4] --r5Pyd7+fXNt84Ff3-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 09:26:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17669; Wed, 19 Nov 2003 09:26:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTHN-0004Be-68; Wed, 19 Nov 2003 09:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTGT-0004BC-2P for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 09:25:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17637 for ; Wed, 19 Nov 2003 09:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTGR-0007jQ-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 09:25:03 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AMTGQ-0007jN-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 09:25:02 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAJEOfGn031837; Wed, 19 Nov 2003 09:24:50 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Stig Venaas'" Cc: "'Tim Chown'" , "'Ralph Droms'" , Subject: RE: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Date: Wed, 19 Nov 2003 09:24:48 -0500 Message-ID: <000601c3aea8$e65a4440$6401a8c0@BVolz> 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.4510 In-Reply-To: <20031119132852.GD9257@sverresborg.uninett.no> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Stig: >What should client do if it can't update the configured data. I = strongly >feel it should keep it and retry. But how often. Can it be a function = of >the lifetime, or would we need an additional value? RFC 3315, section 18.1.5, already covers the sending and retransmission = of the Information-Request. I think that the client should keep retrying = (just as if it was booted and was trying to obtain configuration information initially). The only difference being that the client SHOULD continue to = use the information it has until it is successful in updating the = information and refreshing the lifetime. I also feel that the client MUST use a random time delay before sending = the first Information-Request after the valid lifetime expires. Think of the situation where all the clients are time synchronized ... if the server = sent a lifetime based on an absolute time of when a configuration change was scheduled or all of the clients booted nearly at the same time, the = server could be flooded with lots of requests (as INF_MAX_DELAY is one second = and most clients will likely use timers with 1 second resolution, they may = all detect the expired lifetime simultaneously). >When should client add it to the option request list and when should >server put it in replies. I have some SHOULD/MAY text which may need >to be changed. I think what you have is fine. >The usage should be pretty clear. In unstable environments the value >can be set to a small value. If a renumbering or other changes are >planned, the administrator can gradually decrease the value, similar >to DNS and ttls. I think adding something about this to the draft would be beneficial. It might also be worth while to move the text in the Introduction about = how a client uses this information to a separate section. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Stig Venaas Sent: Wednesday, November 19, 2003 8:29 AM To: Bernie Volz Cc: 'Tim Chown'; 'Ralph Droms'; dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? I've now submitted the draft draft-venaas-dhc-lifetime-00.txt on a lifetime timer. Which is one of the options in Tim's document. I also think this is one of the better approaches. Draft is attached. On Tue, Nov 18, 2003 at 07:41:25PM -0500, Bernie Volz wrote: [...] > So what actions are needed? >=20 > 1. Someone needs to publish a "valid lifetime" draft. Tim, are you planning > on doing this? Ralph? [...] So this is done (: I have some open questions. What should client do if it can't update the configured data. I strongly feel it should keep it and retry. But how often. Can it be a function of the lifetime, or would we need an additional value? When should client add it to the option request list and when should server put it in replies. I have some SHOULD/MAY text which may need to be changed. The usage should be pretty clear. In unstable environments the value can be set to a small value. If a renumbering or other changes are planned, the administrator can gradually decrease the value, similar to DNS and ttls. Hope for some discussion on this and related topics. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 09:53:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18789; Wed, 19 Nov 2003 09:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMThV-0006nO-MA; Wed, 19 Nov 2003 09:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMThQ-0006nD-2V for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 09:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18772 for ; Wed, 19 Nov 2003 09:52:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMThO-0000P3-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 09:52:54 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AMThN-0000Oq-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 09:52:53 -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 hAJEq6pI002270; Wed, 19 Nov 2003 15:52:06 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAJEq6R7009708; Wed, 19 Nov 2003 15:52:06 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAJEq66W009707; Wed, 19 Nov 2003 15:52:06 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Nov 2003 15:52:06 +0100 From: Stig Venaas To: Bernie Volz Cc: "'Tim Chown'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Message-ID: <20031119145206.GM9257@sverresborg.uninett.no> References: <20031119132852.GD9257@sverresborg.uninett.no> <000601c3aea8$e65a4440$6401a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601c3aea8$e65a4440$6401a8c0@BVolz> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Nov 19, 2003 at 09:24:48AM -0500, Bernie Volz wrote: > Thanks Stig: > > >What should client do if it can't update the configured data. I strongly > >feel it should keep it and retry. But how often. Can it be a function of > >the lifetime, or would we need an additional value? > > RFC 3315, section 18.1.5, already covers the sending and retransmission of > the Information-Request. I think that the client should keep retrying (just > as if it was booted and was trying to obtain configuration information > initially). The only difference being that the client SHOULD continue to use > the information it has until it is successful in updating the information > and refreshing the lifetime. Sounds good. > I also feel that the client MUST use a random time delay before sending the > first Information-Request after the valid lifetime expires. Think of the > situation where all the clients are time synchronized ... if the server sent > a lifetime based on an absolute time of when a configuration change was > scheduled or all of the clients booted nearly at the same time, the server > could be flooded with lots of requests (as INF_MAX_DELAY is one second and > most clients will likely use timers with 1 second resolution, they may all > detect the expired lifetime simultaneously). I thought about this. My thinking was that the initial requests were not replied to simultaneously, so it would be ok. But you're quite right. So, after expired lifetime is detected, the request should be delayed a random time between 0 and MAX_DELAY, what should it be? Can we use INF_MAX_DELAY so that the entire update process (both first message and retries) are as in 18.1.5? A larger value would be fine too though, and perhaps safer. > >The usage should be pretty clear. In unstable environments the value > >can be set to a small value. If a renumbering or other changes are > >planned, the administrator can gradually decrease the value, similar > >to DNS and ttls. > > I think adding something about this to the draft would be beneficial. Will do. > It might also be worth while to move the text in the Introduction about how > a client uses this information to a separate section. OK. I'll wait a bit for other comments, and probably post rev 01 soon. Thanks for comments, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 10:18:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21448; Wed, 19 Nov 2003 10:18:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU5g-0000jB-T3; Wed, 19 Nov 2003 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU55-0000ia-0y for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 10:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21267 for ; Wed, 19 Nov 2003 10:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMU52-0000xj-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 10:17:20 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AMU51-0000x3-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 10:17:19 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119085>; Wed, 19 Nov 2003 16:07:52 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Nov 2003 16:16:16 +0100 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Date: Wed, 19 Nov 2003 16:15:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3AEAF.EF0B9790" Subject: [dhcwg] Updated Draft "DHCP Discovery Extensions" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3AEAF.EF0B9790 Content-Type: text/plain Hello DHC-WG, I updated my draft "DHCP Discovery Extensions" to address the issues raised in the past threads in this mailing list. * state diagram drawn * Use of Authentication (RFC 3118) proposed to address the possible DDoS-Attack problem through DHCPNETSCAN. * Default settings on the client defined (NORMAL MODE). * New "Discovery Option" introduced that allows the Server to enable/disable the Discovery Extensions on the client. * Outlined standalone implementation of the "DHCP Discovery Extensions" without full RFC 2131 functionality. (this is of interest for certain types of clients with limited resources, i.e. in the field of industrial automation) <> Please don't hesitate to submit your comments :-) Best Regards, Markus Rentschler ------_=_NextPart_000_01C3AEAF.EF0B9790 Content-Type: text/plain; name="draft-rentschler-dhc-discovery-01.txt" Content-Disposition: attachment; filename="draft-rentschler-dhc-discovery-01.txt" Content-Transfer-Encoding: quoted-printable DHC Markus Rentschler Internet Draft Hirschmann Electronics = =20 Expires: May 2004 November 2003 DHCP Discovery Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The discovery mechanism described here is built upon and coexists with BOOTP according to RFC 1542 and DHCP according to RFC 2131=20 and RFC 3203. It allows server-initiated communication to specific or all clients=20 in the network, using the DHCP packet format and with that the relay agent functionality.=20 The Discovery Extensons are a powerful and flexible add-on to=20 client-initiated DHCP that allow a variety of applications. =20 Rentschler Expires May 2004 [Page = 1] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 Requirements terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. Introduction Host Configuration using "traditional" DHCP according to RFC 2131 is based on host- (client-) initiated communication. If a network is booting, all the clients start sending DHCP requests until=20 accepting an answer from a DHCP server. The server may either allocate IP addresses out of a pool of=20 available adresses or, similar to BOOTP, pre-configured static IP addresses and configuration parameters for each known client. These concepts did not intend server-initiated and -controlled configuration or reconfiguration of clients. This capability was later partially added with RFC 3203, but the mechanism there does not allow to discover "silent" clients yet unknown to a server or trigger the configuration of such a client. =20 This is especially limiting when a server is later plugged to an already configured network.=20 These shortcomings will be overcome with the protocol extensions=20 described in this document, which will provide useful functionality for centralized network administration, for example: - scanning the network for clients even prior to their=20 initialization with IP parameters. Building a database of all=20 clients present in a network.=20 - detecting and identifying duplicate network addresses - administrator controlled reconfiguration of certain clients=20 - server redundancy mechanism The main goal of the discovery extension is to allow as much flexibility as possible for the server to communicate with the client(s) to allow a wide range of applications, which are not subject of this document.=20 The DHCP Discovery Extensions may also be adopted for DHCPv6. Rentschler Expires May 2004 [Page = 2] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 2. The DHCP Discovery Protocol The Discovery Extensions provide a server-initiated communication mechanism that work as follows: The server sends the new DHCPNETSCAN message into the network,=20 either as broadcast to all clients or directed to a certain client.=20 The client responds with the new DHCPREPORT message containing=20 the client's actual parameter settings. A server that receives=20 the DHCPREPORT message SHOULD use the information contained in=20 this message to maintain its internal database (list of clients=20 and leases).=20 For the configuration of a certain client the server sends the=20 new DHCPCONFIGURE message to this client that contains all parameters that the server wishes to transfer to the client. The client responds with a DHCPREPORT message back to the=20 server(s) to indicate if it accepted the new configuration=20 parameters. The DHCP client MUST maintain its internal database and MUST -if it accepted new IP settings- terminate an already existing lease by sending a DHCPRELEASE message towards the initially lease granting server. One of the intentions of the DHCP Discovery Extension is to work with an inactive DHCP client (in terms that the client is not = sending initial DHCPDISCOVER messages) to allow the configuration process be entirely performed and controlled by the administrator's management station, without having the network flooded with=20 DHCPDISCOVER-Requests at powerup.=20 This mode shall be referred to as SILENT MODE. In SILENT MODE The client is always ready to receive and processs = the new DHCPNETSCAN and DHCPDISCOVER messages according to the = procedures described in this document. In this mode the Authentication Option [RFC 3118] from a server MAY be ignored. The SILENT MODE is however only an optional mode of operation that MAY be configured on the client. Clients with limited resources MAY only implement the Discovery Extensions, therefore not supporting full DHCP functionality according to RFC 2131. The DHCP Discovery Extensions MUST also work with an active client that is sending initial DHCPDISCOVER messages.=20 This mode shall be referred to as NORMAL MODE. In NORMAL MODE the Discovery Extensions MUST only be enabled through the DHCP Server by the new "Discovery Option" that MAY be = transferred for this purpose from the server to the client. If in this mode the authentication mechanism according to RFC 3118=20 is used, authentication MUST also be applied to the new Discovery=20 Extension messages.=20 The NORMAL MODE is RECOMMENDED as default setting on the client. Rentschler Expires May 2004 [Page = 3] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 3. New DHCP message types and options Three messages MUST be added to the set of existing DHCP messages: DHCPNETSCAN DHCPCONFIGURE DHCPREPORT The value of the message types -to be encoded in DHCP option 53- is left as TBD until assigned by IANA. Existing correct implementations of DHCP clients or servers SHOULD ignore and discard these new message types. =20 To existing correct implementations of BOOTP relay agents these new message types SHOULD be transparent. The usage of the 'Parameter Request List' Option gets extended = within the scope of this document. RFC 2131 and RFC 2132 limit the use of this option in direction from client to server. The new message=20 types defined in this document are allowed to transfer the = 'Parameter Request List' option also from server to client. 3.1 DHCPNETSCAN message The DHCPNETSCAN message is sent from a server to one client (unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay agent's other subnets.=20 Its purpose is to request the client's actual parameter settings=20 and report them to the server(s) by triggering a DHCPREPORT message. Field Contents ----- ------------=20 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server=20 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address=20 'yiaddr' 0 'siaddr' IP address of server 'giaddr' 0 or the target relay agent's interface IP adress 'chaddr' 0 or client's hardware address 'sname' unused 'file' unused 'options' 53: DHCP Message Type: DHCPNETSCAN 54: Server Identifier 55: Parameter Request List=20 82: Relay information option (MAY be used for path = information,=20 if a relay is involved in transportation to the = client) Rentschler Expires May 2004 [Page = 4] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 3.2 DHCPCONFIGURE message The DHCPCONFIGURE message is sent from a server to a certain client. Its purpose is to provide the client with new parameter settings.=20 Field Contents ----- ------------=20 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server=20 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address=20 'yiaddr' IP address for client 'siaddr' IP address of server 'giaddr' 0 =20 'chaddr' 0 or client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 53: DHCP Message Type: DHCPCONFIGURE 54: Server Identifier 55: Parameter Request List=20 additional any other option, which must then also be present in the parameter request list.=09 It is RECOMMENDED that upon ip configuration the following options SHOULD be included: 01: Subnet Mask 03: Router 51: IP address lease time 61: Client-Identifier For reconfiguration of single non-ip parameters, only the options=20 representing these parameters are required to transmit. =20 =20 Rentschler Expires May 2004 [Page = 5] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 3.3 DHCPREPORT message The purpose of this message is to report the client's actual=20 parameter settings to one or all servers. It is the acknowledgement towards the server upon a DHCPNETSCAN or DHCPCONFIGURE request. The DHCPREPORT message is sent from a client to a server as broadcast or unicast, depending on the 'BROADCAST' flag in the original DHCPNETSCAN or DHCPCONFIGURE message and the state of the client's IP stack. A client that has not yet assigned a=20 valid IP address SHOULD always broadcast this message,=20 using 0.0.0.0 as source address and the limited broadcast=20 address 255.255.255.255 as destination address. Field Contents ----- ------------=20 'op' BOOTREQUEST (RFC 2131: client to server direction) 'xid' 'xid' from server=20 'secs' 0 or seconds since DHCP process started 'flags' flags from DHCPNETSCAN or DHCPNETCONIFG message 'ciaddr' 0 or client's network address=20 'yiaddr' IP address of client 'siaddr' 0=20 'giaddr' 0 =20 'chaddr' client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 53: DHCP Message Type: DHCPREPORT 54: Server Identifier 57: Maximum DHCP Message Size additional all supported options requested=20 in DHCPNETSCAN or DHCPCONFIGURE. The client MUST omit any options it cannot provide. Rentschler Expires May 2004 [Page = 6] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 3.4 Discovery Option The purpose of this option is to configure and report the state of the Discovery Extensions on the client.=20 The Discovery Option is an 8-bit number. Code Len Value +-----+-----+-----+ | TBD | 1 | a | +-----+-----+-----+ The code for this option is TBD, and its length is 1. The Discovery Option uses the following values: DiscoveryDisabled 0 DiscoveryEnabled 1 DiscoveryOnly 2 Clients that support the Discovery Extensions MUST add the Discovery Option to the list of options included in its DHCPDISCOVER and=20 DHCPREQUEST messages. An absence of this option indicates that the client does not support the Discovery Extensions. If this option is requested by the server in a DHCPNETSCAN or=20 DHCPCONFIGURE message, it MUST be included in the DHCPREPORT = message. The server MAY include the Discovery Option in a DHCPACK message or=20 a DHCPCONFIGURE message to configure the Discovery Extensions on the client.=20 The value DiscoveryOnly(3) MUST be transferred from client to server to indicate that only the Discovery Extensions are supported on this client, but not full RFC 2131 functionality. In this case a server=20 MUST always assign infinite leases. In SILENT MODE the client MAY ignore the Discovery Option sent from=20 a server. Rentschler Expires May 2004 [Page = 7] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 4. Extended DHCP state diagram +--------+ +------+ | Init / | +-->+ Init +<---------------+-------------------+ | Reboot | | +--+---+ | | +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | | Restart | (broadcast) | | | | v v-------------+ | | -/Send DHCPREQUEST| +----+------+ DHCPOFFER/DHCPDECLINE | | (broadcast)| | Selecting |----------+ | | v | +----+------+ | | +---+----+ | DHCPOFFER/DHCPREQUEST | | | Reboot +---------+ (broadcast) | | +---+----+ v | | | +----+-------+ DHCPNAK /halt network | + Requesting | | lease expired DHCPACK/ +----+-------+ | | Record lease | | | set timers DHCPACK/Record lease | | | v Set T1 & T2 | | | +--+----+DHCPFORCE +---+---+ = +----+---+ +----------------->+ BOUND +---------->+ Renew +--------->+ Rebind = | +--+-+--+T1 expires +-+-+---+T2 = expires+----+---+ ^ /DHCPREQUEST | | /broadcast | DHCPACK to leasing | | DHCPREQUEST | | server | | | +----------------------------------------+ =20 =20 =20 +----------+ =20 +------------>+ Discover | =20 | +-----+----+ =20 | | =20 | DHCPNETSCAN/Send DHCPREPORT =20 | | =20 | | =20 | | =20 | DHCPCONFIGURE/Send DHCPRELEASE if appropriate = =20 | | Send DHCPREPORT =20 | | Record lease =20 | | Set T1 & T2 =20 | | Set main state =3D BOUND = | | =20 +-------------------+ Note: The "Discover" state is a parallel state that runs independently from the DHCP main state machine. Rentschler Expires May 2004 [Page = 8] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 =20 5. The DHCP Server DHCP Server implementations MAY incorporate any administrative=20 controls or policies desired by network administrators that make use of the underlying protocol described in this and related documents. DHCP servers that support the protocol described in this document MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages,=20 either automatically at startup, program controlled, in certain intervals and/or on manual requests.=20 The content of the BROADCAST flag in the DHCPNETSCAN and DHCPCONFIGURE messages SHOULD be configurable and disabled by default. The DHCP server MUST be able to receive DHCPREPORT messages and=20 SHOULD use them to verify the state of pending requests.=20 The 'xid' field SHOULD be used by the server to match incoming DHCP=20 messages with pending requests.=20 Pending requests SHOULD be supervised using a timeout mechanism.=20 The timeout value MUST be configurable and SHOULD have a default value of 4 seconds.=20 A retransmission strategy for unacknowledged requests SHOULD be=20 implemented. The server MAY use all received DHCPREPORT messages to build and maintain an internal database (based on IP addresses), that MAY=20 contain all known leases in the network. This database MAY be=20 periodically updated by sending DHCPNETSCAN messages.=20 If a server receives a DHCPREPORT message for a lease that was=20 granted by itself, the contents MUST be checked for consistency with the internal lease database.=20 If any inconsistency is detected (i.e. unknown MAC address or=20 wrong relay agent information option contents), these DHCPREPORTS MUST be ignored and their occurence MUST be reported to the=20 administrator. It is RECOMMENDED that a timeout mechanism removes expired leases=20 in this database. The server MUST be able to renew and rebind existing leases which were granted by itself. The server MAY be able to rebind existing leases which were not=20 granted by itself, but are listed in its internal database as known leases. This feature should be configurable and disabled by default. If duplicate IP addresses are detected in the database, the server SHOULD report this to the administrator. If duplicate client identifiers (DHCP Option 61) are detected in the database, the server SHOULD report this to the administrator. Rentschler Expires May 2004 [Page = 9] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 6. The DHCP Client The DHCP client needs to be modified to incorporate the handling of=20 the new message types. In NORMAL MODE the use of message authentication following the=20 procedures described in RFC 3118 is RECOMMENDED.=20 If authentication is used, the DHCPNETSCAN and DHCPCONFIGURE=20 messages MUST also be authenticated by the client. If the Discovery Extensions are enabled and -if applicable- proper=20 authentication took place, the client MUST process received=20 DHCPNETSCAN and DHCPCONFIGURE messages as described in this = document. It answers these messages from the server with the message = DHCPREPORT and return in it the requested parameters to the server. DHCPREPORT contains always the client's current parameter settings. The client MUST omit any parameters it cannot provide. The sending of a broadcast DHCPREPORT message that was generated in response to a DHCPNETSCAN message SHOULD be delayed a random time interval up to 2 seconds to prevent broadcast storms on the network. DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently discarded and not queued for processing. =20 The Discovery Extensions run in their own parallel state 'Discover', that is not influenced by the client's main state. The client's handling of a received DHCPNETSCAN message SHOULD be the same in every state of the DHCP client's state machine. It = SHOULD not affect the current state of the client's state machine.=20 The receipt of a DHCPCONFIGURE message MUST result in the following actions: If the message and the parameters offered to the client are correct the new parameters MUST be accepted. An existing lease MUST be=20 terminated by sending a DHCPRELEASE message. Then the client's IP=20 stack is initialized with the new parameters and the client sends a DHCPREPORT to the server, containing the new parameter settings. Then the DHCP client's main state machine is set to the state BOUND and starts its timers T1 and T2 for the renewing/rebinding process. Rentschler Expires May 2004 [Page = 10] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 7. The BOOTP Relay Agent =20 DHCPNETSCAN messages that are received as IP broadcast on one of the relay's interfaces MUST be broadcasted in all other IP subnets accessible by this relay agent.=20 This option SHOULD be configurable and disabled by default.=20 DHCPNETSCAN messages that are received as IP unicast directed to=20 one of the relay agent's IP interfaces and have the giaddr field set to the same interface address MUST be broadcasted only on the physical ports attached to this IP interface. This allows scanning of a specified subnet. This option SHOULD be configurable and disabled by default.=20 If one of the above packets -directed to the client- has the relay agent information option present, this field SHOULD be examined. If the contents of the Agent Remote ID matches the relay agent's unique identifier (i.e. MAC, Client-Id or an IP address) AND the=20 Agent Circuit ID suboption contains a valid physical port number, this information SHOULD be used to forward the DHCPNETSCAN=20 message to the client.=20 Rentschler Expires May 2004 [Page = 11] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 8. Security Considerations In this section possible security attacks and prevention=20 mechanisms will be discussed. - Distributed Denial of Service attacks through DHCPNETSCAN A bogus server may flood the network with broadcast DHCPNETSCAN messages at such a rate, that due to multiple client responses=20 other communication will slow down. In order to keep damage low in case of such an attack, the client delays the generation of the DHCPREPORT message and discards=20 DHCPNETSCAN messages that were received in the meantime.=20 In NORMAL MODE an authentication mechanism [RFC 3118] SHOULD be used to verify the integrity of the server. - Denial of Service attacks through DHCPCONFIGURE A bogus server may send DHCPCONFIGURE packets to misconfigure=20 clients in the network.=20 In Normal MODE an authentication mechanism [RFC 3118] SHOULD be used to verify the integrity of the server. - Denial of Service attacks through DHCPREPORT A bogus client may send DHCPREPORT packets into the network to misinform servers about existing leases in the network.=20 A server that has granted a lease needs to check incoming=20 DHCPREPORTS concerning this lease for consistency. If authentication [RFC 3118] is used, the integrity of such bogus=20 messages can be checked and subsequently discarded. =20 =20 9. IANA Considerations The value for the new message types=20 =20 DHCPNETSCAN DHCPCONFIGURE DHCPREPORT and the new "Discovery Option" must be assigned from the numbering space defined for message types ond options in RFC 2939. Rentschler Expires May 2004 [Page = 12] =0C Internet-Draft DHCP Discovery Extensions Dec = 2003 10. References RFC 1542 W. Wimer, October 1993, "Clarifications/Extensions for the Bootstrap Protocol", RFC 2131 R. Droms, March 1997,=20 "The Dynamic Host Configuration Protocol",=20 RFC 2939 R. Droms, September 2000,=20 "Procedures an IANA guidelines for Definition of new DHCP Options and Message Types",=20 RFC 3046, M. Patrick, January 2001,=20 "DHCP Relay Agent Information Option",=20 RFC 3118 R. Droms and W. Arbaugh, June 2001,=20 "Authentication for DHCP Messages", RFC 3203, Y. T'Joens et. al., December 2001,=20 "DHCP reconfigure extension",=20 11. Acknowledgments We Acknowledge the help of .... and all the members of the development department at Hirschmann Electronics GmbH & Co. KG. 12. Author's Address Markus Rentschler Hirschmann Electronics GmbH & Co. KG, Neckartenzlingen, Germany. Email: mrentsch@nt.hirschmann.de Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Rentschler Expires May 2004 [Page = 13] ------_=_NextPart_000_01C3AEAF.EF0B9790-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 11:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23220; Wed, 19 Nov 2003 11:02:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUmG-0003AH-6X; Wed, 19 Nov 2003 11:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUlM-00039r-Lp for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 11:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23199 for ; Wed, 19 Nov 2003 11:00:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUlK-0001h8-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:01:02 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AMUlJ-0001h5-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:01:01 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAJG08Ar058840; Wed, 19 Nov 2003 11:00:12 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Stig Venaas'" Cc: "'Tim Chown'" , "'Ralph Droms'" , Subject: RE: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug? Date: Wed, 19 Nov 2003 11:00:15 -0500 Message-ID: <000201c3aeb6$38f88d80$6401a8c0@BVolz> 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.4510 In-Reply-To: <20031119145206.GM9257@sverresborg.uninett.no> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >So, after expired lifetime is detected, the request should be delayed a >random time between 0 and MAX_DELAY, what should it be? Can we use >INF_MAX_DELAY so that the entire update process (both first message and >retries) are as in 18.1.5? A larger value would be fine too though, and >perhaps safer. I think INF_MAX_DELAY would be fine. The point is to desynchronize the requests and that will do the trick. If the server is still overloaded, the retransmissions will handle that as those clients that failed to receive a response will just retry. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 11:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24488; Wed, 19 Nov 2003 11:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV7Z-0004X4-Dc; Wed, 19 Nov 2003 11:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV7C-0004Wi-Lg for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 11:23:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24469 for ; Wed, 19 Nov 2003 11:23:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMV7B-0002Ht-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:23:37 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AMV7A-0002Hq-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:23:37 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 0F5F01C0228D; Wed, 19 Nov 2003 14:26:36 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id VAA06851; Wed, 19 Nov 2003 21:52:16 +0530 (IST) Message-ID: <3FBB98FC.30700@india.hp.com> Date: Wed, 19 Nov 2003 21:53:24 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: DHCPWG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Abstract > > This document describes an option for specifying lifetime of other > configuration options. It's mainly intended for the stateless DHCP, > but also useful when there are no addresses or other entities with > lifetimes that can tell the client when to contact the DHCP server > and update its configuration. > > s/DHCP/DHCPv6/g > 1. Introduction > > For IPv6 many hosts will use stateless autoconfiguration as specified > in [RFC 2462] for address assignment, and use DHCP for other > configuration data. This other configuration data will typically have > no associated lifetime, hence there may be no information telling a > host when to update its DHCP configuration data. > > you may want to refer draft-chown-dhc-stateless-dhcpv6-renumbering-00 here > The option specified here tells the host the lifetime of the > configuration data. When the lifetime expires, the host should make a > new DHCP request, updating the current configuration. This request > would usually be an Information request. If the host fails to update > the information, it should keep the current configuration, and retry > at regular intervals. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in BCP 14, RFC 2119 [RFC > 2119]. > > > 3. Lifetime option definition > > A client supporting this option SHOULD include it in the Option > Request option when sending an Information-request message to the > DHCP server. > > I guess, it is applicable for Request also... Moreover, why do you want to make the client to send this option always in the ORO option.. The better way could be, Whenever the server provides non-address configuration, it MUST include Lifetime option in the reply" Opinions? Moreover, you should explain what the client is expected to do with this option... Since, you are introducing the lifetime for non-address params, you have to explain what the client should do if the lifetime expires... I am thinking about a model, where there will be 2 lifetimes, preferred and valid.. Once the preferred life time expires, it should start unicasting the Information-request to renew the configure information.... By this way, it is possible to refresh the parameters even before it expire.. Once the valid life time expires, it should send a multicast Information-Request to All Relays mutlicast address... But, It should ignore the old configuration *only* after obtaining the configuration info from some other server.... You need to add text about the retransmission mechanism also... Look at RFC 3315.. It has some timer values associated with Information-Request INF_MAX_DELAY 1 sec Max delay of first Information-request INF_TIMEOUT 1 sec Initial Information-request timeout INF_MAX_RT 120 secs Max Information-request timeout value Add text on client behavior and server behavior to explain it clearly.... You need to add some thing like, "If the client has address configuration obtained from the server, the client MAY ignore this option and send renew along with the IAs" > The format of the Lifetime option is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_LIFETIME | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > option-code: OPTION_LIFETIME (to be decided) > > option-len: 4 > > You need to change this option if you decide to use two timers... > lifetime: lifetime in seconds > > can you explain it bit more here... you may need to explain what are all the possible values it can have? Is 0 valid? Do you want to provide the permanent lease with 0xffffffff? Or do you want to make 0xffffffff reserved ? I guess, the server should be able to make the lifetime as 0, to make the client stop using the configuration and initiate the fresh Information-request/Reply to obtain new configuration information.. 0xffffffff can be assumed as infinite lease and can be used in the network where the configuration is stable and there wont be any change in it.... > > 4. IANA Considerations > > IANA is requested to assign an option-code for the lifetime option > from the option-code space defined in [RFC 3315]. > > The format should be something like.... IANA is requested to assign an option code to the following options from the option-code space defined in "DHCPv6 Options" section of the DHCPv6 specification [1]. Option Name Value Described in OPTION_NIS_SERVERS tbd Section 4 OPTION_NISP_SERVERS tbd Section 5 OPTION_NIS_DOMAIN_NAME tbd Section 6 OPTION_NISP_DOMAIN_NAME tbd Section 7 The key is, you need to mention the Section # > > 5. Acknowledgments > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > 6. Security Considerations > > This option is believed not have any effects on security. > > No.. There are security constraints...Any intruder can frame a reply packet with a very less life time in the lifetime option and make the clients to intiate requests in very short intervals, making the network flooded and servers overloaded.... DHCP authentication as defined in RFC 3315 should be used for authentication... You need to add a section where you should list the only messages in which this option can appear... Something like... 8. Appearance of these options The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The option number for these options MAY appear in the Option Request Option [1] in the following messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 11:39:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25205; Wed, 19 Nov 2003 11:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVM5-0005gY-Ta; Wed, 19 Nov 2003 11:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVLg-0005fe-3P for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 11:38:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25168 for ; Wed, 19 Nov 2003 11:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVLd-0002ci-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:38:33 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVLc-0002cW-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 11:38:32 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA17091 for ; Wed, 19 Nov 2003 16:38:31 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA15329 for ; Wed, 19 Nov 2003 16:38:31 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAJGcVx16323 for dhcwg@ietf.org; Wed, 19 Nov 2003 16:38:31 GMT Date: Wed, 19 Nov 2003 16:38:31 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Updated Draft "DHCP Discovery Extensions" Message-ID: <20031119163831.GE11170@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Presumably this is only aimed at DHCPv4? Tim On Wed, Nov 19, 2003 at 04:15:14PM +0100, Rentschler, Markus wrote: > Hello DHC-WG, > > I updated my draft "DHCP Discovery Extensions" to address the issues raised > in the past threads in this mailing list. > > * state diagram drawn > > * Use of Authentication (RFC 3118) proposed to address the possible > DDoS-Attack problem through DHCPNETSCAN. > > * Default settings on the client defined (NORMAL MODE). > > * New "Discovery Option" introduced that allows the Server to enable/disable > the Discovery Extensions on the client. > > * Outlined standalone implementation of the "DHCP Discovery Extensions" > without full RFC 2131 functionality. > (this is of interest for certain types of clients with limited resources, > i.e. in the field of industrial automation) > > <> > > Please don't hesitate to submit your comments :-) > > Best Regards, > Markus Rentschler > > DHC Markus Rentschler > Internet Draft Hirschmann Electronics > Expires: May 2004 November 2003 > > > DHCP Discovery Extensions > > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > > Abstract > > The discovery mechanism described here is built upon and coexists > with BOOTP according to RFC 1542 and DHCP according to RFC 2131 > and RFC 3203. > It allows server-initiated communication to specific or all clients > in the network, using the DHCP packet format and with that the > relay agent functionality. > The Discovery Extensons are a powerful and flexible add-on to > client-initiated DHCP that allow a variety of applications. > > > > > > > > > > Rentschler Expires May 2004 [Page 1] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > Requirements terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119. > > > > 1. Introduction > > Host Configuration using "traditional" DHCP according to RFC 2131 > is based on host- (client-) initiated communication. If a network > is booting, all the clients start sending DHCP requests until > accepting an answer from a DHCP server. > The server may either allocate IP addresses out of a pool of > available adresses or, similar to BOOTP, pre-configured static > IP addresses and configuration parameters for each known client. > > These concepts did not intend server-initiated and -controlled > configuration or reconfiguration of clients. This capability was > later partially added with RFC 3203, but the mechanism there does > not allow to discover "silent" clients yet unknown to a server or > trigger the configuration of such a client. > This is especially limiting when a server is later plugged to an > already configured network. > These shortcomings will be overcome with the protocol extensions > described in this document, which will provide useful functionality > for centralized network administration, for example: > > - scanning the network for clients even prior to their > initialization with IP parameters. Building a database of all > clients present in a network. > - detecting and identifying duplicate network addresses > - administrator controlled reconfiguration of certain clients > - server redundancy mechanism > > The main goal of the discovery extension is to allow as much > flexibility as possible for the server to communicate with the > client(s) to allow a wide range of applications, which are not > subject of this document. > > The DHCP Discovery Extensions may also be adopted for DHCPv6. > > > > > > > > > > Rentschler Expires May 2004 [Page 2] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 2. The DHCP Discovery Protocol > > The Discovery Extensions provide a server-initiated communication > mechanism that work as follows: > > The server sends the new DHCPNETSCAN message into the network, > either as broadcast to all clients or directed to a certain client. > The client responds with the new DHCPREPORT message containing > the client's actual parameter settings. A server that receives > the DHCPREPORT message SHOULD use the information contained in > this message to maintain its internal database (list of clients > and leases). > > For the configuration of a certain client the server sends the > new DHCPCONFIGURE message to this client that contains all > parameters that the server wishes to transfer to the client. > The client responds with a DHCPREPORT message back to the > server(s) to indicate if it accepted the new configuration > parameters. The DHCP client MUST maintain its internal database > and MUST -if it accepted new IP settings- terminate an already > existing lease by sending a DHCPRELEASE message towards the > initially lease granting server. > > One of the intentions of the DHCP Discovery Extension is to work > with an inactive DHCP client (in terms that the client is not sending > initial DHCPDISCOVER messages) to allow the configuration process be > entirely performed and controlled by the administrator's > management station, without having the network flooded with > DHCPDISCOVER-Requests at powerup. > This mode shall be referred to as SILENT MODE. > In SILENT MODE The client is always ready to receive and processs the > new DHCPNETSCAN and DHCPDISCOVER messages according to the procedures > described in this document. In this mode the Authentication Option > [RFC 3118] from a server MAY be ignored. > The SILENT MODE is however only an optional mode of operation that > MAY be configured on the client. Clients with limited resources MAY > only implement the Discovery Extensions, therefore not supporting > full DHCP functionality according to RFC 2131. > > The DHCP Discovery Extensions MUST also work with an active client > that is sending initial DHCPDISCOVER messages. > This mode shall be referred to as NORMAL MODE. > In NORMAL MODE the Discovery Extensions MUST only be enabled through > the DHCP Server by the new "Discovery Option" that MAY be transferred > for this purpose from the server to the client. > If in this mode the authentication mechanism according to RFC 3118 > is used, authentication MUST also be applied to the new Discovery > Extension messages. > The NORMAL MODE is RECOMMENDED as default setting on the client. > > > Rentschler Expires May 2004 [Page 3] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 3. New DHCP message types and options > > Three messages MUST be added to the set of existing DHCP messages: > > DHCPNETSCAN > DHCPCONFIGURE > DHCPREPORT > > The value of the message types -to be encoded in DHCP option 53- > is left as TBD until assigned by IANA. > > Existing correct implementations of DHCP clients or servers SHOULD > ignore and discard these new message types. > To existing correct implementations of BOOTP relay agents these new > message types SHOULD be transparent. > The usage of the 'Parameter Request List' Option gets extended within > the scope of this document. RFC 2131 and RFC 2132 limit the use of > this option in direction from client to server. The new message > types defined in this document are allowed to transfer the 'Parameter > Request List' option also from server to client. > > > 3.1 DHCPNETSCAN message > > The DHCPNETSCAN message is sent from a server to one client > (unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN > message SHOULD be broadcasted into a relay agent's other subnets. > Its purpose is to request the client's actual parameter settings > and report them to the server(s) by triggering a DHCPREPORT message. > > Field Contents > ----- ------------ > 'op' BOOTREPLY (RFC 2131: server to client direction) > 'xid' 'xid' from server > 'secs' 0 > 'flags' Set 'BROADCAST' flag if server requires broadcast reply > 'ciaddr' 0 or client's network address > 'yiaddr' 0 > 'siaddr' IP address of server > 'giaddr' 0 or the target relay agent's interface IP adress > 'chaddr' 0 or client's hardware address > 'sname' unused > 'file' unused > 'options' 53: DHCP Message Type: DHCPNETSCAN > 54: Server Identifier > 55: Parameter Request List > 82: Relay information option (MAY be used for path information, > if a relay is involved in transportation to the client) > > > > Rentschler Expires May 2004 [Page 4] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 3.2 DHCPCONFIGURE message > > The DHCPCONFIGURE message is sent from a server to a certain client. > Its purpose is to provide the client with new parameter settings. > > > Field Contents > ----- ------------ > 'op' BOOTREPLY (RFC 2131: server to client direction) > 'xid' 'xid' from server > 'secs' 0 > 'flags' Set 'BROADCAST' flag if server requires broadcast reply > 'ciaddr' 0 or client's network address > 'yiaddr' IP address for client > 'siaddr' IP address of server > 'giaddr' 0 > 'chaddr' 0 or client's hardware address > 'sname' Server host name or options > 'file' Client boot file name or options > 'options' 53: DHCP Message Type: DHCPCONFIGURE > 54: Server Identifier > 55: Parameter Request List > additional any other option, which must then also be > present in the parameter request list. > > It is RECOMMENDED that upon ip configuration the following options > SHOULD be included: > 01: Subnet Mask > 03: Router > 51: IP address lease time > 61: Client-Identifier > > For reconfiguration of single non-ip parameters, only the options > representing these parameters are required to transmit. > > > > > > > > > > > > > > > > > > Rentschler Expires May 2004 [Page 5] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 3.3 DHCPREPORT message > > The purpose of this message is to report the client's actual > parameter settings to one or all servers. It is the acknowledgement > towards the server upon a DHCPNETSCAN or DHCPCONFIGURE request. > > The DHCPREPORT message is sent from a client to a server as > broadcast or unicast, depending on the 'BROADCAST' flag in the > original DHCPNETSCAN or DHCPCONFIGURE message and the state of > the client's IP stack. A client that has not yet assigned a > valid IP address SHOULD always broadcast this message, > using 0.0.0.0 as source address and the limited broadcast > address 255.255.255.255 as destination address. > > > Field Contents > ----- ------------ > 'op' BOOTREQUEST (RFC 2131: client to server direction) > 'xid' 'xid' from server > 'secs' 0 or seconds since DHCP process started > 'flags' flags from DHCPNETSCAN or DHCPNETCONIFG message > 'ciaddr' 0 or client's network address > 'yiaddr' IP address of client > 'siaddr' 0 > 'giaddr' 0 > 'chaddr' client's hardware address > 'sname' Server host name or options > 'file' Client boot file name or options > 'options' 53: DHCP Message Type: DHCPREPORT > 54: Server Identifier > 57: Maximum DHCP Message Size > additional all supported options requested > in DHCPNETSCAN or DHCPCONFIGURE. > > The client MUST omit any options it cannot provide. > > > > > > > > > > > > > > > > > Rentschler Expires May 2004 [Page 6] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 3.4 Discovery Option > > The purpose of this option is to configure and report the state > of the Discovery Extensions on the client. > The Discovery Option is an 8-bit number. > > Code Len Value > +-----+-----+-----+ > | TBD | 1 | a | > +-----+-----+-----+ > > The code for this option is TBD, and its length is 1. > > The Discovery Option uses the following values: > > DiscoveryDisabled 0 > DiscoveryEnabled 1 > DiscoveryOnly 2 > > Clients that support the Discovery Extensions MUST add the Discovery > Option to the list of options included in its DHCPDISCOVER and > DHCPREQUEST messages. An absence of this option indicates > that the client does not support the Discovery Extensions. > > If this option is requested by the server in a DHCPNETSCAN or > DHCPCONFIGURE message, it MUST be included in the DHCPREPORT message. > > The server MAY include the Discovery Option in a DHCPACK message or > a DHCPCONFIGURE message to configure the Discovery Extensions on the > client. > > The value DiscoveryOnly(3) MUST be transferred from client to server > to indicate that only the Discovery Extensions are supported on this > client, but not full RFC 2131 functionality. In this case a server > MUST always assign infinite leases. > > In SILENT MODE the client MAY ignore the Discovery Option sent from > a server. > > > > > > > > > > > > > > Rentschler Expires May 2004 [Page 7] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 4. Extended DHCP state diagram > > +--------+ +------+ > | Init / | +-->+ Init +<---------------+-------------------+ > | Reboot | | +--+---+ | | > +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | > | Restart | (broadcast) | | > | | v v-------------+ | | > -/Send DHCPREQUEST| +----+------+ DHCPOFFER/DHCPDECLINE | > | (broadcast)| | Selecting |----------+ | | > v | +----+------+ | | > +---+----+ | DHCPOFFER/DHCPREQUEST | | > | Reboot +---------+ (broadcast) | | > +---+----+ v | | > | +----+-------+ DHCPNAK /halt network > | + Requesting | | lease expired > DHCPACK/ +----+-------+ | | > Record lease | | | > set timers DHCPACK/Record lease | | > | v Set T1 & T2 | | > | +--+----+DHCPFORCE +---+---+ +----+---+ > +----------------->+ BOUND +---------->+ Renew +--------->+ Rebind | > +--+-+--+T1 expires +-+-+---+T2 expires+----+---+ > ^ /DHCPREQUEST | | /broadcast | > DHCPACK to leasing | | DHCPREQUEST | > | server | | | > +----------------------------------------+ > > > > +----------+ > +------------>+ Discover | > | +-----+----+ > | | > | DHCPNETSCAN/Send DHCPREPORT > | | > | | > | | > | DHCPCONFIGURE/Send DHCPRELEASE if appropriate > | | Send DHCPREPORT > | | Record lease > | | Set T1 & T2 > | | Set main state = BOUND > | | > +-------------------+ > > > Note: The "Discover" state is a parallel state that runs independently > from the DHCP main state machine. > > > Rentschler Expires May 2004 [Page 8] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 5. The DHCP Server > > DHCP Server implementations MAY incorporate any administrative > controls or policies desired by network administrators that make use > of the underlying protocol described in this and related documents. > > DHCP servers that support the protocol described in this document > MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages, > either automatically at startup, program controlled, in certain > intervals and/or on manual requests. > > The content of the BROADCAST flag in the DHCPNETSCAN and > DHCPCONFIGURE messages SHOULD be configurable and disabled > by default. > > The DHCP server MUST be able to receive DHCPREPORT messages and > SHOULD use them to verify the state of pending requests. > > The 'xid' field SHOULD be used by the server to match incoming DHCP > messages with pending requests. > Pending requests SHOULD be supervised using a timeout mechanism. > The timeout value MUST be configurable and SHOULD have a default > value of 4 seconds. > A retransmission strategy for unacknowledged requests SHOULD be > implemented. > > The server MAY use all received DHCPREPORT messages to build and > maintain an internal database (based on IP addresses), that MAY > contain all known leases in the network. This database MAY be > periodically updated by sending DHCPNETSCAN messages. > If a server receives a DHCPREPORT message for a lease that was > granted by itself, the contents MUST be checked for consistency > with the internal lease database. > If any inconsistency is detected (i.e. unknown MAC address or > wrong relay agent information option contents), these DHCPREPORTS > MUST be ignored and their occurence MUST be reported to the > administrator. > > It is RECOMMENDED that a timeout mechanism removes expired leases > in this database. > The server MUST be able to renew and rebind existing leases which > were granted by itself. > The server MAY be able to rebind existing leases which were not > granted by itself, but are listed in its internal database as known > leases. This feature should be configurable and disabled by default. > > If duplicate IP addresses are detected in the database, the server > SHOULD report this to the administrator. > If duplicate client identifiers (DHCP Option 61) are detected in > the database, the server SHOULD report this to the administrator. > > Rentschler Expires May 2004 [Page 9] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 6. The DHCP Client > > The DHCP client needs to be modified to incorporate the handling of > the new message types. > > In NORMAL MODE the use of message authentication following the > procedures described in RFC 3118 is RECOMMENDED. > If authentication is used, the DHCPNETSCAN and DHCPCONFIGURE > messages MUST also be authenticated by the client. > > If the Discovery Extensions are enabled and -if applicable- proper > authentication took place, the client MUST process received > DHCPNETSCAN and DHCPCONFIGURE messages as described in this document. > It answers these messages from the server with the message DHCPREPORT > and return in it the requested parameters to the server. > DHCPREPORT contains always the client's current parameter settings. > The client MUST omit any parameters it cannot provide. > > The sending of a broadcast DHCPREPORT message that was generated > in response to a DHCPNETSCAN message SHOULD be delayed a random time > interval up to 2 seconds to prevent broadcast storms on the network. > DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently > discarded and not queued for processing. > > The Discovery Extensions run in their own parallel state 'Discover', > that is not influenced by the client's main state. > The client's handling of a received DHCPNETSCAN message SHOULD be > the same in every state of the DHCP client's state machine. It SHOULD > not affect the current state of the client's state machine. > > The receipt of a DHCPCONFIGURE message MUST result in the > following actions: > If the message and the parameters offered to the client are correct > the new parameters MUST be accepted. An existing lease MUST be > terminated by sending a DHCPRELEASE message. Then the client's IP > stack is initialized with the new parameters and the client sends a > DHCPREPORT to the server, containing the new parameter settings. > Then the DHCP client's main state machine is set to the state BOUND > and starts its timers T1 and T2 for the renewing/rebinding process. > > > > > > > > > > > > > Rentschler Expires May 2004 [Page 10] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 7. The BOOTP Relay Agent > > DHCPNETSCAN messages that are received as IP broadcast on one of > the relay's interfaces MUST be broadcasted in all other IP subnets > accessible by this relay agent. > This option SHOULD be configurable and disabled by default. > > DHCPNETSCAN messages that are received as IP unicast directed to > one of the relay agent's IP interfaces and have the giaddr field > set to the same interface address MUST be broadcasted only on the > physical ports attached to this IP interface. This allows scanning > of a specified subnet. > This option SHOULD be configurable and disabled by default. > > If one of the above packets -directed to the client- has the relay > agent information option present, this field SHOULD be examined. > If the contents of the Agent Remote ID matches the relay agent's > unique identifier (i.e. MAC, Client-Id or an IP address) AND the > Agent Circuit ID suboption contains a valid physical port number, > this information SHOULD be used to forward the DHCPNETSCAN > message to the client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rentschler Expires May 2004 [Page 11] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 8. Security Considerations > > In this section possible security attacks and prevention > mechanisms will be discussed. > > - Distributed Denial of Service attacks through DHCPNETSCAN > > A bogus server may flood the network with broadcast DHCPNETSCAN > messages at such a rate, that due to multiple client responses > other communication will slow down. > In order to keep damage low in case of such an attack, the client > delays the generation of the DHCPREPORT message and discards > DHCPNETSCAN messages that were received in the meantime. > In NORMAL MODE an authentication mechanism [RFC 3118] SHOULD be used > to verify the integrity of the server. > > > - Denial of Service attacks through DHCPCONFIGURE > > A bogus server may send DHCPCONFIGURE packets to misconfigure > clients in the network. > In Normal MODE an authentication mechanism [RFC 3118] SHOULD be used > to verify the integrity of the server. > > > - Denial of Service attacks through DHCPREPORT > > A bogus client may send DHCPREPORT packets into the network to > misinform servers about existing leases in the network. > A server that has granted a lease needs to check incoming > DHCPREPORTS concerning this lease for consistency. > If authentication [RFC 3118] is used, the integrity of such bogus > messages can be checked and subsequently discarded. > > > > 9. IANA Considerations > > The value for the new message types > > DHCPNETSCAN > DHCPCONFIGURE > DHCPREPORT > > and the new "Discovery Option" must be assigned from the numbering > space defined for message types ond options in RFC 2939. > > > > > > Rentschler Expires May 2004 [Page 12] > > Internet-Draft DHCP Discovery Extensions Dec 2003 > > > 10. References > > RFC 1542 W. Wimer, October 1993, > "Clarifications/Extensions for the Bootstrap Protocol", > RFC 2131 R. Droms, March 1997, > "The Dynamic Host Configuration Protocol", > RFC 2939 R. Droms, September 2000, > "Procedures an IANA guidelines for Definition > of new DHCP Options and Message Types", > RFC 3046, M. Patrick, January 2001, > "DHCP Relay Agent Information Option", > RFC 3118 R. Droms and W. Arbaugh, June 2001, > "Authentication for DHCP Messages", > RFC 3203, Y. T'Joens et. al., December 2001, > "DHCP reconfigure extension", > > > 11. Acknowledgments > > We Acknowledge the help of .... and all the members of the > development department at Hirschmann Electronics GmbH & Co. KG. > > 12. Author's Address > > Markus Rentschler > Hirschmann Electronics GmbH & Co. KG, > Neckartenzlingen, > Germany. > Email: mrentsch@nt.hirschmann.de > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into. > > > > > Rentschler Expires May 2004 [Page 13] > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 12:25:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27914; Wed, 19 Nov 2003 12:25:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW4b-0000jn-5B; Wed, 19 Nov 2003 12:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW3x-0000ih-5N for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 12:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27883 for ; Wed, 19 Nov 2003 12:24:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMW3v-0003vF-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 12:24:19 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AMW3u-0003ua-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 12:24:19 -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 hAJHNmpI001096; Wed, 19 Nov 2003 18:23:48 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAJHNlR7009957; Wed, 19 Nov 2003 18:23:47 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAJHNlb6009956; Wed, 19 Nov 2003 18:23:47 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Nov 2003 18:23:47 +0100 From: Stig Venaas To: Vijayabhaskar A K Cc: DHCPWG Subject: Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt Message-ID: <20031119172347.GA9907@sverresborg.uninett.no> References: <3FBB98FC.30700@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBB98FC.30700@india.hp.com> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Nov 19, 2003 at 09:53:24PM +0530, Vijayabhaskar A K wrote: > > A client supporting this option SHOULD include it in the Option > > Request option when sending an Information-request message to the > > DHCP server. > > > > > I guess, it is applicable for Request also... Moreover, why do you want > to make the client to send this option always in the ORO option.. The > better way could be, Whenever the server provides non-address > configuration, it MUST include Lifetime option in the reply" Opinions? I'm pretty open on this point, not sure which is best. > I am thinking about a model, where there will be 2 lifetimes, preferred > and valid.. Once the preferred life time expires, it should start > unicasting the Information-request to renew the configure > information.... By this way, it is possible to refresh the parameters > even before it expire.. Once the valid life time expires, it should > send a multicast Information-Request to All Relays mutlicast address... > But, It should ignore the old configuration *only* after obtaining the > configuration info from some other server.... I'm not sure this is necessary, would like to get more opinions on this. > You need to add text about the retransmission mechanism also... Look at > RFC 3315.. It has some timer values associated with Information-Request > > INF_MAX_DELAY 1 sec Max delay of first Information-request > INF_TIMEOUT 1 sec Initial Information-request timeout > INF_MAX_RT 120 secs Max Information-request timeout value Will do. > Add text on client behavior and server behavior to explain it clearly.... > > You need to add some thing like, "If the client has address > configuration obtained from the server, the client MAY ignore this > option and send renew along with the IAs" Right. I can say that it's only used for options not having a specified lifetime of their own, and if client sends a request, renew, rebind or information-request message to the DHCP server before the lifetime has expired, it MAY update all this data as well. Actually, I think SHOULD might be appropriate. Are those the correct message types? > you may need to explain what are all the possible values it can have? Is > 0 valid? Do you want to provide the permanent lease with 0xffffffff? Or > do you want to make 0xffffffff reserved ? I guess, the server should be > able to make the lifetime as 0, to make the client stop using the > configuration and initiate the fresh Information-request/Reply to obtain But can't the server immediately offer the options, instead of setting it to 0 and have a new request? > new configuration information.. 0xffffffff can be assumed as infinite > lease and can be used in the network where the configuration is stable > and there wont be any change in it.... Maybe, but omitting the option or not supporting it should be the same, right? > >4. IANA Considerations > > > > IANA is requested to assign an option-code for the lifetime option > > from the option-code space defined in [RFC 3315]. > > > > > The format should be something like.... > > IANA is requested to assign an option code to the following options > from the option-code space defined in "DHCPv6 Options" section of the > DHCPv6 specification [1]. ok, will change this. > No.. There are security constraints...Any intruder can frame a reply > packet with a very less life time in the lifetime option and make the > clients to intiate requests in very short intervals, making the network > flooded and servers overloaded.... DHCP authentication as defined in RFC > 3315 should be used for authentication... My thinking is that the current lifetime value is forgotten when it expires. Then when you get new config info, you'll either have a correct value, or no value meaning infinite or unspecified (as it is when option isn't supported). Obviously something that needs to be spelled out in next version. > You need to add a section where you should list the only messages in > which this option can appear... Something like... > > 8. Appearance of these options > > The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name > options MUST NOT appear in other than the following messages: Solicit, > Advertise, Request, Renew, Rebind, Information-Request and Reply. > > The option number for these options MAY appear in the Option Request > Option [1] in the following messages: Solicit, Request, Renew, > Rebind, Information-Request and Reconfigure. Will do, thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 13:18:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01041; Wed, 19 Nov 2003 13:18:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWtt-0005BC-0M; Wed, 19 Nov 2003 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWtg-00059b-Iq for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 13:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01025 for ; Wed, 19 Nov 2003 13:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWte-0005gP-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 13:17:46 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AMWtd-0005gK-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 13:17:46 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 5D87C1C003E9; Wed, 19 Nov 2003 16:59:43 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id XAA15141; Wed, 19 Nov 2003 23:45:49 +0530 (IST) Message-ID: <3FBBB398.2030101@india.hp.com> Date: Wed, 19 Nov 2003 23:46:56 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas Cc: DHCPWG Subject: Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt References: <3FBB98FC.30700@india.hp.com> <20031119172347.GA9907@sverresborg.uninett.no> In-Reply-To: <20031119172347.GA9907@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Wed, Nov 19, 2003 at 09:53:24PM +0530, Vijayabhaskar A K wrote: > > >>> A client supporting this option SHOULD include it in the Option >>> Request option when sending an Information-request message to the >>> DHCP server. >>> >>> >>> >>> >>I guess, it is applicable for Request also... Moreover, why do you want >>to make the client to send this option always in the ORO option.. The >>better way could be, Whenever the server provides non-address >>configuration, it MUST include Lifetime option in the reply" Opinions? >> >> > >I'm pretty open on this point, not sure which is best. > > Including this option in the ORO somehow makes this option unrelated to non-address configuration.. But it is not so.... They are tied together and server should be able to send this option if any of the non-address conf are requested.. The key thing is, life time is part of the non-address conf > > >>I am thinking about a model, where there will be 2 lifetimes, preferred >>and valid.. Once the preferred life time expires, it should start >>unicasting the Information-request to renew the configure >>information.... By this way, it is possible to refresh the parameters >>even before it expire.. Once the valid life time expires, it should >>send a multicast Information-Request to All Relays mutlicast address... >>But, It should ignore the old configuration *only* after obtaining the >>configuration info from some other server.... >> >> > >I'm not sure this is necessary, would like to get more opinions on this. > > > >>You need to add text about the retransmission mechanism also... Look at >>RFC 3315.. It has some timer values associated with Information-Request >> >>INF_MAX_DELAY 1 sec Max delay of first Information-request >> INF_TIMEOUT 1 sec Initial Information-request timeout >> INF_MAX_RT 120 secs Max Information-request timeout value >> >> > >Will do. > > > >>Add text on client behavior and server behavior to explain it clearly.... >> >>You need to add some thing like, "If the client has address >>configuration obtained from the server, the client MAY ignore this >>option and send renew along with the IAs" >> >> > >Right. I can say that it's only used for options not having a specified >lifetime of their own, and if client sends a request, renew, rebind or >information-request message to the DHCP server before the lifetime has >expired, it MAY update all this data as well. > > Sounds good.. >Actually, I think SHOULD might be appropriate. Are those the correct >message types? > > yes, the intention here is, instead of mainitaining two seperate life times for address and non-address conf, the clients can include the renewal of these info whenever it gets a chance to contact the server.. you can even say. this life time can be ignored, till it have a configuration which has associated life time in it.. > > >>you may need to explain what are all the possible values it can have? Is >>0 valid? Do you want to provide the permanent lease with 0xffffffff? Or >>do you want to make 0xffffffff reserved ? I guess, the server should be >>able to make the lifetime as 0, to make the client stop using the >>configuration and initiate the fresh Information-request/Reply to obtain >> >> > >But can't the server immediately offer the options, instead of setting >it to 0 and have a new request? > > It may choose to stop serving this link and may want trigger the client to use some other dhcp server > > >>new configuration information.. 0xffffffff can be assumed as infinite >>lease and can be used in the network where the configuration is stable >>and there wont be any change in it.... >> >> > >Maybe, but omitting the option or not supporting it should be the same, >right? > > yes.. but, in dhcp terms 0xffffffff has a meaning of infinite lease.. Do you want to keep it? > > >>>4. IANA Considerations >>> >>> IANA is requested to assign an option-code for the lifetime option >>> from the option-code space defined in [RFC 3315]. >>> >>> >>> >>> >>The format should be something like.... >> >>IANA is requested to assign an option code to the following options >> from the option-code space defined in "DHCPv6 Options" section of the >> DHCPv6 specification [1]. >> >> > >ok, will change this. > > > >>No.. There are security constraints...Any intruder can frame a reply >>packet with a very less life time in the lifetime option and make the >>clients to intiate requests in very short intervals, making the network >>flooded and servers overloaded.... DHCP authentication as defined in RFC >>3315 should be used for authentication... >> >> > >My thinking is that the current lifetime value is forgotten when it >expires. Then when you get new config info, you'll either have a >correct value, or no value meaning infinite or unspecified (as it is >when option isn't supported). Obviously something that needs to be >spelled out in next version. > > > certainly, you have somethings to be added in this section >>You need to add a section where you should list the only messages in >>which this option can appear... Something like... >> >>8. Appearance of these options >> >> The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name >> options MUST NOT appear in other than the following messages: Solicit, >> Advertise, Request, Renew, Rebind, Information-Request and Reply. >> >> The option number for these options MAY appear in the Option Request >> Option [1] in the following messages: Solicit, Request, Renew, >> Rebind, Information-Request and Reconfigure. >> >> > >Will do, thanks, > >Stig > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 15:21:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09290; Wed, 19 Nov 2003 15:21:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYp2-0004Y8-Ln; Wed, 19 Nov 2003 15:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYok-0004Wl-1e for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 15:20:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09117; Wed, 19 Nov 2003 15:20:36 -0500 (EST) Message-Id: <200311192020.PAA09117@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Nov 2003 15:20:36 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-03.txt Pages : 8 Date : 2003-11-19 A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agentopt-radius-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-03.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: <2003-11-19144151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144151.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 18:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23603; Wed, 19 Nov 2003 18:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc1J-0006kO-KU; Wed, 19 Nov 2003 18:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc1H-0006kB-Tf for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 18:45:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23574 for ; Wed, 19 Nov 2003 18:45:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc1E-0006QP-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 18:45:56 -0500 Received: from smtp107.mail.sc5.yahoo.com ([66.163.169.227]) by ietf-mx with smtp (Exim 4.12) id 1AMc1D-0006QI-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 18:45:55 -0500 Received: from adsl-64-169-90-78.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp-v1.mail.vip.sc5.yahoo.com with SMTP; 19 Nov 2003 23:45:55 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] LDAP Schema for DHCP Date: Wed, 19 Nov 2003 15:46:07 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <000001c3adf9$45e9d480$6401a8c0@BVolz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit there certainly are servers capable of processing thousands of DHCP messages per second, and I personally know of environments where the steady-state message rate (7x24) is roughly 4-7 messages per second with peak rates in excess of 3000 messages per second, with client populations measured in tens or hundreds of thousands. so before over specifying an LDAP schema, one probably should define the problem space a bit taking into account actual usage patterns that would have to be accommodated, rather than just devising something in the abstract that might not be implementable. --Barr > -----Original Message----- > From: Bernie Volz > Sent: Tuesday, November 18, 2003 09:28 > > It all depends on what you want to use LDAP for. > > There's: > - Configuration information for the server or service (whether implemented > in one or many servers). And, there's also the "current" vs. the "next" > configuration to consider. > - Active lease information (this is, IMO, the easiest to standardize since > it is well defined based on RFC 2131/2132). Such as what client > is using the > address and which options were sent to it. > - Historical lease information (what clients had what addresses when). > > And, there are probably other uses that I haven't mentioned. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 18:51:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23821; Wed, 19 Nov 2003 18:51:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc6A-0006xH-Ty; Wed, 19 Nov 2003 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc5W-0006uQ-3p for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 18:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23775 for ; Wed, 19 Nov 2003 18:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc5S-0006Xe-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 18:50:19 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc5S-0006Xa-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 18:50:18 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA26608 for ; Wed, 19 Nov 2003 23:50:16 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA23786 for ; Wed, 19 Nov 2003 23:50:16 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAJNoGY23990 for dhcwg@ietf.org; Wed, 19 Nov 2003 23:50:16 GMT Date: Wed, 19 Nov 2003 23:50:16 +0000 From: Tim Chown To: DHCPWG Subject: Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt Message-ID: <20031119235016.GJ23381@login.ecs.soton.ac.uk> Mail-Followup-To: DHCPWG References: <3FBB98FC.30700@india.hp.com> <20031119172347.GA9907@sverresborg.uninett.no> <3FBBB398.2030101@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBBB398.2030101@india.hp.com> User-Agent: Mutt/1.4i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Nov 19, 2003 at 11:46:56PM +0530, Vijayabhaskar A K wrote: > > > It may choose to stop serving this link and may want trigger the client > to use some other dhcp server Hmm, that's an interesting special case, where the DHCPv6 server is itself being renumbered or changed. Might be worth an explicit mention in the text? Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 19:48:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26770; Wed, 19 Nov 2003 19:48:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMczJ-0001RK-FK; Wed, 19 Nov 2003 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcyK-0001Ql-Tx for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 19:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26675 for ; Wed, 19 Nov 2003 19:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcyI-00002H-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 19:46:58 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AMcyI-00002B-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 19:46:58 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAK0kVAr073840; Wed, 19 Nov 2003 19:46:39 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Tim Chown'" , "'DHCPWG'" Subject: RE: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt Date: Wed, 19 Nov 2003 19:46:36 -0500 Message-ID: <000001c3aeff$c3b2e300$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <20031119235016.GJ23381@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable FYI: RFC 3315 states in Section 15, Message Validation: A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address. So, Information-Request *MUST* be multicast. It may not be unicast. = (Also, even if this rule were relaxed, the client MUST NOT unicast unless it receives a Server Unicast option). I don't see a need for a preferred and valid lifetime for configuration information. Just a lifetime is sufficient. We should NOT call this a = "valid lifetime" as that has a well understood meaning in IPv6. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Tim Chown Sent: Wednesday, November 19, 2003 6:50 PM To: DHCPWG Subject: Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt On Wed, Nov 19, 2003 at 11:46:56PM +0530, Vijayabhaskar A K wrote: > > > It may choose to stop serving this link and may want trigger the = client=20 > to use some other dhcp server Hmm, that's an interesting special case, where the DHCPv6 server is = itself being renumbered or changed. Might be worth an explicit mention in the text? =20 Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 19 19:51:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27021; Wed, 19 Nov 2003 19:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd2D-0001cU-R6; Wed, 19 Nov 2003 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd1y-0001cA-1s for dhcwg@optimus.ietf.org; Wed, 19 Nov 2003 19:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26999 for ; Wed, 19 Nov 2003 19:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMd1w-0000B8-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 19:50:44 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AMd1v-0000Aq-00 for dhcwg@ietf.org; Wed, 19 Nov 2003 19:50:43 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 4E4681B2003; Wed, 19 Nov 2003 18:50:34 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] LDAP Schema for DHCP Date: Wed, 19 Nov 2003 18:50:33 -0600 To: X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 19, 2003, at 5:46 PM, Barr Hibbs wrote: > so before over specifying an LDAP schema, one probably should define > the > problem space a bit taking into account actual usage patterns that > would > have to be accommodated, rather than just devising something in the > abstract > that might not be implementable. On the other hand, there's no technical reason why an LDAP server can't handle 3k updates per second - it's just a stereotype that LDAP servers can't do that. I don't even know if it's still true. So if what's desired is to keep a complete lease record in LDAP, or if that's one part of an LDAP schema that can also be used just for configuration information, I think it's fine. The real question is, is this actually something that people want? If not, why not wait until people want it? If so, do people want the whole thing, or just configuration information? If they just want configuration information, why not define that schema now but leave room to add more later? As to Bernie's point, I think you can make the case that conditional behavior is something that can be thought of as separate from actual configuration, and there are ways to write the LDAP schema so that it provides support for whatever conditional behavior the server offers, without actually encoding that behavior - that is, you don't have to stuff the ISC config language, python code, or whatever into the LDAP database - just the objects that that code manipulates. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 20 02:49:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21456; Thu, 20 Nov 2003 02:49:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjYj-0005X9-Au; Thu, 20 Nov 2003 02:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjXr-0005W3-Hv for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 02:48:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21370 for ; Thu, 20 Nov 2003 02:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjXo-0005gR-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 02:48:04 -0500 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1AMjXn-0005fl-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 02:48:04 -0500 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119098>; Thu, 20 Nov 2003 08:38:05 +0100 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Thu, 20 Nov 2003 08:46:32 +0100 Message-ID: From: "Rentschler, Markus" To: Tim Chown , dhcwg@ietf.org Subject: AW: [dhcwg] Updated Draft "DHCP Discovery Extensions" Date: Thu, 20 Nov 2003 08:46:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This draft adresses only the DHCPv4 packet format,=20 although the underlying mechanism could also be adopted to IPv6. Markus > -----Urspr=FCngliche Nachricht----- > Von: Tim Chown [SMTP:tjc@ecs.soton.ac.uk] > Gesendet am: Mittwoch, 19. November 2003 17:39 > An: dhcwg@ietf.org > Betreff: Re: [dhcwg] Updated Draft "DHCP Discovery Extensions" >=20 > Presumably this is only aimed at DHCPv4? >=20 > Tim >=20 > On Wed, Nov 19, 2003 at 04:15:14PM +0100, Rentschler, Markus wrote: > > Hello DHC-WG, > >=20 > > I updated my draft "DHCP Discovery Extensions" to address the = issues > raised > > in the past threads in this mailing list. > >=20 > > * state diagram drawn > >=20 > > * Use of Authentication (RFC 3118) proposed to address the possible > > DDoS-Attack problem through DHCPNETSCAN.=20 > >=20 > > * Default settings on the client defined (NORMAL MODE). > >=20 > > * New "Discovery Option" introduced that allows the Server to > enable/disable > > the Discovery Extensions on the client.=20 > >=20 > > * Outlined standalone implementation of the "DHCP Discovery = Extensions" > > without full RFC 2131 functionality. > > (this is of interest for certain types of clients with limited > resources, > > i.e. in the field of industrial automation) > >=20 > > <>=20 > >=20 > > Please don't hesitate to submit your comments :-) > >=20 > > Best Regards, > > Markus Rentschler >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 20 03:02:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23258; Thu, 20 Nov 2003 03:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjlJ-0006TY-VM; Thu, 20 Nov 2003 03:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjlA-0006T7-7B for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 03:01:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23151 for ; Thu, 20 Nov 2003 03:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjl7-00064j-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 03:01:49 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AMjl6-00061a-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 03:01:48 -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 hAK813pI014861; Thu, 20 Nov 2003 09:01:03 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAK813R7011278; Thu, 20 Nov 2003 09:01:03 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAK812RA011274; Thu, 20 Nov 2003 09:01:02 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 20 Nov 2003 09:01:02 +0100 From: Stig Venaas To: Ted Lemon Cc: rbhibbs@pacbell.net, dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP Message-ID: <20031120080102.GB11248@sverresborg.uninett.no> References: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> User-Agent: Mutt/1.4.1i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Nov 19, 2003 at 06:50:33PM -0600, Ted Lemon wrote: > The real question is, is this actually something that people want? If > not, why not wait until people want it? If so, do people want the > whole thing, or just configuration information? If they just want > configuration information, why not define that schema now but leave > room to add more later? There's already an LDAP patch for ISC DHCP, and a schema to go with it. I think it's for configuration only, not sure. Found it using google a few days ago, don't have the URL at hand, but should be easy to find. So there seems to be some that want it... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 20 09:27:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05642; Thu, 20 Nov 2003 09:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpls-0004zj-QM; Thu, 20 Nov 2003 09:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMplq-0004zU-0E for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 09:26:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05593; Thu, 20 Nov 2003 09:26:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMplo-0003fF-00; Thu, 20 Nov 2003 09:26:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpln-0003dw-00; Thu, 20 Nov 2003 09:26:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 06:26:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEQMw5006221; Thu, 20 Nov 2003 06:26:23 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED18524; Thu, 20 Nov 2003 09:26:21 -0500 (EST) Message-Id: <4.3.2.7.2.20031120092059.01ead240@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 09:26:18 -0500 To: From: Ralph Droms Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Cc: iesg@ietf.org In-Reply-To: <4.3.2.7.2.20031113213303.026f0448@flask.cisco.com> References: <4.3.2.7.2.20031113074713.01e59b18@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In response to comments from Pekka about the description of the function of relay agents in providing stateless DHCPv6 service, is there any objection to adding the following paragraph as the last paragraph in section 3, "Overview", of draft-ietf-dhc-dhcpv6-stateless-02.txt: This document does not apply to the function of DHCPv6 relay agents as described in RFc 3315. A network element can provide both DHCPv6 service to some clients, while relaying messages for other clients to another DHCPv6 server. For example, a network element can provide stateless DHCPv6 service to hosts requesting stateless DHCP service, while relaying messages from hosts requesting address assignment through DHCPv6 to another DHCPv6 server. - Ralph At 08:05 AM 11/14/2003 -0500, Ralph Droms wrote: >At 04:13 PM 11/13/2003 +0200, Pekka Savola wrote: > >On Thu, 13 Nov 2003, Ralph Droms wrote: > > > Pekka - thanks for your review. My responses to your comments are > inline. > > > >Thanks.. just a few responses inline. > > > >(Btw -- does the case I mentioned off-line about first-hop router being a > >stateless DHCP server, but acting as DHCP relay for stateful DHCP need to > >be explicitly mentioned -- I guess so?) > >Recognizing that a network element can be both a server and a relay >agent has evolved in DHCPv4 without any explicit text - there's nothing >in the DHPCv4 specifications that disallows such behavior. > >If there is consensus that text allowing a network element to act >as both a DHCPv6 server and relay agent would be useful, we can add >it to this doc... > > > > At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote: > > > >On Thu, 30 Oct 2003, The IESG wrote: > > > >1) the spec is not sufficiently clear how the relays behave in a mixed > > world > > > >of stateless/stateful DHCP service. That is, would deploying a > > > >stateless-only relay (if such a thing is possible?) harm the > stateful DHCP > > > >clients? Is the implementation of a relay any different for > > full/stateless > > > >DHCP service, etc. ?: > > > > > > > > The operation of relay agents is the same for stateless and stateful > > > > DHCPv6 service. The operation of relay agents is described in the > > > > DHCPv6 specification. > > > > > > The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are > > > all completely defined in RFC 3315. From the point of view of the > > > DHCPv6 relay agent, there is no difference between the subset of > > > RFC 3315 referred to as "stateless DHCPv6" and the full set of > > > functions in RFC 3315. > > > > > > More concisely, there are just "DHCPv6 relay agents" that work with both > > > full RFC 3315 clients and stateless-only clients... > > > >Right. I think this should be spelled out in the stateless document a bit > >better, that the stateless DHCP has to implement "full" relay service, > >which is of course rather lightweight in itself (it has no state, I > >believe). > >I would rather add text like: > > This document does not apply to the behavior of DHCPv6 relay agents. > > > > >==> that is, do relays really *flood* these messages to all the DHCPv6 > > > >servers they know, so that if one doesn't process the request but > silently > > > >ignores it, the others can step up and handle the job? See also the > point > > > >1) above. > > > > > > Yes, a relay agent forwards a copy of each message it receives from a > > client > > > to each of the servers in its configured list of servers. > > > >Are all the responses equally flooded back to the relay as well? > >Yes - in this regard a DHCPv6 relay agent works the same as a >DHCPv4 relay agent. > > > Does the > >relay pick and respond to the hosts with first or all the information? > > > >(Just trying to clarify, this probably doesn't need changes in the spec.) > >No. > > > > > 1-4: give an introduction to DHCPv6 and an overview of DHCP > message > > > > flows > > > > > > > >==> some of those flows are redundant to Stateless DHCPv6 operation, > > > >though.. :-) > > > > > > OK, would a more precise list (e.g., individual subsections rather than > > > simply "1-4") be helpful? > > > >That might not hurt. However, what I was referring to was that e.g. > >"message flows" or sections like do not really reflect the stateless DHCP > >operation... > >OK. > >- Ralph > > >-- > >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 20 10:52:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10170; Thu, 20 Nov 2003 10:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMr69-0002q4-4x; Thu, 20 Nov 2003 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMr65-0002pn-0u for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 10:51:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10149 for ; Thu, 20 Nov 2003 10:51:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMr62-0004wq-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 10:51:54 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AMr61-0004wn-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 10:51:54 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 381B81B207C; Thu, 20 Nov 2003 09:51:44 -0600 (CST) In-Reply-To: <20031120080102.GB11248@sverresborg.uninett.no> References: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> <20031120080102.GB11248@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <746BE4DE-1B71-11D8-8438-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ted Lemon , rbhibbs@pacbell.net From: Ted Lemon Subject: Re: [dhcwg] LDAP Schema for DHCP Date: Thu, 20 Nov 2003 09:51:50 -0600 To: Stig Venaas X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 20, 2003, at 2:01 AM, Stig Venaas wrote: > There's already an LDAP patch for ISC DHCP, and a schema to go with > it. I think it's for configuration only, not sure. Found it using > google a few days ago, don't have the URL at hand, but should be > easy to find. So there seems to be some that want it... Yup. It's not clear that the LDAP patch in the ISC server is what the ISC would want to adopt, but I agree that there seems to be at least some demand for it. CMU tends historically to be pretty serious about developing good sysadmin tools, so it's worth paying attention to what they're doing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From csbinfo@geocities.com Thu Nov 20 21:29:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14319; Thu, 20 Nov 2003 21:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN13X-0001is-00; Thu, 20 Nov 2003 21:29:59 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AN13W-0001in-00; Thu, 20 Nov 2003 21:29:58 -0500 Received: from [210.22.160.178] (helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AN13V-0007RI-JE; Thu, 20 Nov 2003 21:29:59 -0500 From: "Informe Exclusivo" To: conneg-archive@ietf.org Subject: Fórum Social Brasileiro: radiografia das esquerdas ref.: ohs 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: Thu, 20 Nov 2003 21:29:59 -0500 c0311fsbavisop

hdi EstaCartaEnCastellano - ThisLetterInEnglish

Amigos:

O Primeiro Fórum Social Brasileiro (FSB) efetuou-se de 6 a 9 de novembro pp. na cidade brasileira de Belo Horizonte. Organizado pelo conselho brasileiro do Fórum Social Mundial (FSM), contou com a participação de 1.200 organizações brasileiras, de 15 mil ativistas inscritos oficialmente e de outros 15 mil convidados, entre os quais, observadores de 22 países.

O importante evento, um dos maiores até aqui realizados pelas esquerdas brasileiras, passou desapercebido aos grandes meios de comunicação.

O FSB foi marcado por conferências de cunho comuno-anárquico no político, oposto à propriedade privada e a livre iniciativa; e permissivistas no moral, a favor do aborto, da homossexualidade e da "transversalidade". Constituiu uma oportunidade única para obter uma radiografia atualizada das esquerdas brasileiras, com suas novas e velhas estratégias, seus dilemas, suas utopias, suas contradições internas, seus problemas e seus temores. Uma radiografia indispensável para conhecer o que poderá passar no curto e médio prazo com o regime Lula, com o Brasil e, em boa medida, com a América do Sul.

Oferecemos-lhes gratuitamente um Informe Exclusivo, com 5 capítulos, sobre tal evento.

Cordialmente, Roberto Fernández-Lopez, Ámbito Iberoamericano, Madri.

FSB:InformeCompletoGratuito(EnCastellano)

FSB:InformeCompletoGratuito(EmPortugues)

FSB:FullReport(InEnglish)

Série Fórum Social Brasileiro: radiografia das esquerdas

(Belo Horizonte, Nov. 6-9, 2003)

 

1) FSB: radiografia das esquerdas

Importante congresso de movimentos contestátarios brasileiros passa desapercebido aos grandes meios de comunicação

2) FSB: esquerdas debatem utopias, estratégias e dilemas

Os fantasmas de governos de esquerda derrocados na América Latina ressurgem em meio de ásperos debates

3) FSB: conjuntura latino-americana e política externa lulista

Recolocar o socialismo como uma alternativa viável e derrotar os Estados Unidos são duas das metas internacionais das esquerdas no FSB

4) FSB: articulações de "esquerda católica", MST e indigenistas

Uma "nova lógica" de construção do poder, através de "redes" de ONGs, para controlar o Estado e a sociedade

5) FSB: a meta de "desconstrução" e "reinvenção" do homem e da sociedade

Uma mudança de mentalidades que afaste o mais possivel o ser humano dos Mandamentos da Lei de Deus

LINKS:

FSB:InformeCompletoGratuito(EmPortuguês)

FSB:FullReportInEnglish

FSB:InformeCompletoGratuito(EnCastellano)

FSB:MinhaOpinao

FSB:MinhaSugestao

FSB:Unsubscribe-Br

  

 

 From dhcwg-admin@ietf.org Sat Nov 22 01:33:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21915; Sat, 22 Nov 2003 01:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANRKH-0004na-O8; Sat, 22 Nov 2003 01:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANRJi-0004nC-8W for dhcwg@optimus.ietf.org; Sat, 22 Nov 2003 01:32:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21873 for ; Sat, 22 Nov 2003 01:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANRJf-0000xy-00 for dhcwg@ietf.org; Sat, 22 Nov 2003 01:32:23 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1ANRJe-0000xu-00 for dhcwg@ietf.org; Sat, 22 Nov 2003 01:32:22 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAM6VXj18947; Sat, 22 Nov 2003 07:31:35 +0100 Message-ID: <3FBF02C3.9070009@it.su.se> Date: Sat, 22 Nov 2003 07:31:31 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Stig Venaas CC: Ted Lemon , rbhibbs@pacbell.net, dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP References: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> <20031120080102.GB11248@sverresborg.uninett.no> In-Reply-To: <20031120080102.GB11248@sverresborg.uninett.no> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stig Venaas wrote: | On Wed, Nov 19, 2003 at 06:50:33PM -0600, Ted Lemon wrote: | |>The real question is, is this actually something that people want? If |>not, why not wait until people want it? If so, do people want the |>whole thing, or just configuration information? If they just want |>configuration information, why not define that schema now but leave |>room to add more later? | | | There's already an LDAP patch for ISC DHCP, and a schema to go with | it. I think it's for configuration only, not sure. Found it using | google a few days ago, don't have the URL at hand, but should be | easy to find. So there seems to be some that want it... http://www.lunytune.net/isc-ldap.html. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vwLD8Jx8FtbMZncRAvZQAKCn6+b1BlP6NGoMxMFQ7OdfN79gVACfW33o BOJS4cOx3SByKa7r6D4L6X0= =S+5h -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Nov 22 01:41:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22109; Sat, 22 Nov 2003 01:41:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANRS1-0005Qr-SG; Sat, 22 Nov 2003 01:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANRRn-0005QW-0n for dhcwg@optimus.ietf.org; Sat, 22 Nov 2003 01:40:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22084 for ; Sat, 22 Nov 2003 01:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANRRj-000121-00 for dhcwg@ietf.org; Sat, 22 Nov 2003 01:40:43 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1ANRRj-00011y-00 for dhcwg@ietf.org; Sat, 22 Nov 2003 01:40:43 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAM6dsj18954; Sat, 22 Nov 2003 07:39:55 +0100 Message-ID: <3FBF04BA.6060101@it.su.se> Date: Sat, 22 Nov 2003 07:39:54 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Stig Venaas CC: Ted Lemon , rbhibbs@pacbell.net, dhcwg@ietf.org Subject: Re: [dhcwg] LDAP Schema for DHCP References: <8C24193D-1AF3-11D8-8438-000A95D9C74C@nominum.com> <20031120080102.GB11248@sverresborg.uninett.no> In-Reply-To: <20031120080102.GB11248@sverresborg.uninett.no> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stig Venaas wrote: | On Wed, Nov 19, 2003 at 06:50:33PM -0600, Ted Lemon wrote: | |>The real question is, is this actually something that people want? If |>not, why not wait until people want it? If so, do people want the |>whole thing, or just configuration information? If they just want |>configuration information, why not define that schema now but leave |>room to add more later? | | | There's already an LDAP patch for ISC DHCP, and a schema to go with | it. I think it's for configuration only, not sure. Found it using | google a few days ago, don't have the URL at hand, but should be | easy to find. So there seems to be some that want it... | This schema is very tied to isc dhcp and imo there are better ways to design a general configuration schema but it does show people are interested. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vwS58Jx8FtbMZncRAg3kAJwNxQ8Zef7CMdPRu19deBUfqul9mwCgoqmE PXpLKzlMf2j6zCyoTj0HT+M= =SA7r -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 23 10:51:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23761; Sun, 23 Nov 2003 10:51:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANwVq-0000uh-I6; Sun, 23 Nov 2003 10:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwTb-0006Ax-17 for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 16:36:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29486 for ; Thu, 20 Nov 2003 16:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwTY-0003tW-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 16:36:32 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMwTN-0003sN-00 for dhcwg@ietf.org; Thu, 20 Nov 2003 16:36:21 -0500 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKLZgw5009142 for ; Thu, 20 Nov 2003 13:35:42 -0800 (PST) Received: from cisco.com ([10.34.37.25]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT09284; Thu, 20 Nov 2003 13:35:41 -0800 (PST) Message-ID: <3FBD33C3.9020504@cisco.com> Date: Thu, 20 Nov 2003 13:36:03 -0800 From: Vijay Nain User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Question about DHCP renew Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, My question is specific to the DHCP state machine as defined in RFC 2131. If you feel this is the wrong place to post this question, please accept my apologies, and ignore this mail. I'm working on an 802.11 project, and notice that Win2000 wireless clients do the DHCPDISCOVER (i.e. pretty much start the state machine from scratch), when the radio link is kept down for a period of over 10 seconds and then brought up again. The clients had earlier obtained an IP address correctly, and had IP connectivity to the world. The lease expiration time (or half of it) was significantly in the future in all these cases. From the state machine in the RFC, only a lease refresh timeout should cause the clients to do a renew; it does not look like anything else could force the DHCP client out of the 'bound' state. However, as I mentioned above, whenever I bounce the radio link on the access point long enough, it looks like the DHCP client starts from scratch. Can anyone comment as to whether this is standard DHCP behaviour (of restarting the SM) when the link has been observed to be 'restarted' with a considerable interval in between)? Thanks in advance, Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 23 16:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01187; Sun, 23 Nov 2003 16:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO28F-0004nt-CO; Sun, 23 Nov 2003 16:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO27m-0004n6-6t for dhcwg@optimus.ietf.org; Sun, 23 Nov 2003 16:50:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01092 for ; Sun, 23 Nov 2003 16:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO27k-0007lM-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 16:50:32 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AO27j-0007lE-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 16:50:31 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id BC1D41B200C; Sun, 23 Nov 2003 15:49:48 -0600 (CST) In-Reply-To: <3FBD33C3.9020504@cisco.com> References: <3FBD33C3.9020504@cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D394084-1DFF-11D8-AB46-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Question about DHCP renew Date: Sun, 23 Nov 2003 15:50:28 -0600 To: Vijay Nain X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 20, 2003, at 3:36 PM, Vijay Nain wrote: > However, as I mentioned above, whenever I bounce the radio link on > the access point long enough, it looks like the DHCP client starts > from scratch. > Can anyone comment as to whether this is standard DHCP behaviour (of > restarting the SM) when the link has been observed to be 'restarted' > with a considerable interval in between)? This client is broken. It should probably do a DHCPREQUEST in INIT-REBOOT to solicit information that the lease has changed, but going to the INIT state is not correct here. There's some work going on on a document that addresses these issues - draft-ietf-dhc-dna-ipv4-04.txt. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 23 19:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05686; Sun, 23 Nov 2003 19:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4XG-0002CQ-J9; Sun, 23 Nov 2003 19:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Wu-0002C2-EL for dhcwg@optimus.ietf.org; Sun, 23 Nov 2003 19:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05655 for ; Sun, 23 Nov 2003 19:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ws-0001va-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 19:24:38 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ws-0001vH-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 19:24:38 -0500 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HOT00M01XT0UR@endeavor.poss.com> for dhcwg@ietf.org; Sun, 23 Nov 2003 19:24:07 -0500 (EST) Received: from kan1 (user87.net637.oh.sprint-hsd.net [65.41.58.87]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HOT00I77YG5SA@endeavor.poss.com>; Sun, 23 Nov 2003 19:24:07 -0500 (EST) Date: Sun, 23 Nov 2003 19:24:06 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Question about DHCP renew In-reply-to: <0D394084-1DFF-11D8-AB46-000A95D9C74C@fugue.com> To: dhcwg@ietf.org Cc: Ted Lemon , Vijay Nain Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hmmmm.... Is this client *really* broken? I didn't think the client was *required* to come back in INIT-REBOOT state. In any case, this behavior is not unusual. The WLAN drivers that I have run into frequently treat a loss of carrier the same as a loss of link in a wired network (e.g. someone pulled the cable). In this case the OS (especially Win 2K) may choose to drop all the configuration associated with the NIC and when it regains the carrier (i.e. link) it starts over as if the NIC had just been brought up from scratch. I don't *think* (please correct me if I'm wrong), but I don't think DHCP specifies in that kind of detail what should happen on link loss/acquisition. I do agree that it would probably be best if it started in INIT-REBOOT, but I don't think it's required (again, correct me if I'm wrong). I read draft-ietf-dhc-dna-ipv4-04.txt for the first time just before sending this message. Based on Mr. Aboba's recommendedations INIT-REBOOT would be the correct behavior. However, I don't think the current RFC's actually require this behavior. --kan-- -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted Lemon Sent: Sunday, 23 November, 2003 4:50 PM To: Vijay Nain Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question about DHCP renew On Nov 20, 2003, at 3:36 PM, Vijay Nain wrote: > However, as I mentioned above, whenever I bounce the radio link on > the access point long enough, it looks like the DHCP client starts > from scratch. > Can anyone comment as to whether this is standard DHCP behaviour (of > restarting the SM) when the link has been observed to be 'restarted' > with a considerable interval in between)? This client is broken. It should probably do a DHCPREQUEST in INIT-REBOOT to solicit information that the lease has changed, but going to the INIT state is not correct here. There's some work going on on a document that addresses these issues - draft-ietf-dhc-dna-ipv4-04.txt. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 23 20:04:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06383; Sun, 23 Nov 2003 20:04:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO58y-0003cF-OK; Sun, 23 Nov 2003 20:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO58I-0003Yd-Ni for dhcwg@optimus.ietf.org; Sun, 23 Nov 2003 20:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06368 for ; Sun, 23 Nov 2003 20:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO58G-0002Fl-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 20:03:16 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AO58G-0002Fi-00 for dhcwg@ietf.org; Sun, 23 Nov 2003 20:03:16 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id B130D1B200C; Sun, 23 Nov 2003 19:02:32 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Vijay Nain From: Ted Lemon Subject: Re: [dhcwg] Question about DHCP renew Date: Sun, 23 Nov 2003 19:03:13 -0600 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 23, 2003, at 6:24 PM, Kevin A. Noll wrote: > Is this client *really* broken? I didn't think the client was > *required* to come back in INIT-REBOOT state. No, it's not required to come back into INIT-REBOOT state, but according to the spec it's not really supposed to change states at all in this case. If we had accounted for network link state transitions in RFC2131, I think the right accounting would have been to return to INIT-REBOOT, not INIT, and there seems to be general agreement that this is so. Broken means "not working." I would say that in this case, the client is not working, in the sense that a link state transition kills off existing connections, so yes, it is broken. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 24 15:33:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27733; Mon, 24 Nov 2003 15:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONOG-0006lM-Kh; Mon, 24 Nov 2003 15:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONNP-0006kK-3X for dhcwg@optimus.ietf.org; Mon, 24 Nov 2003 15:32:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27408; Mon, 24 Nov 2003 15:31:52 -0500 (EST) Message-Id: <200311242031.PAA27408@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Nov 2003 15:31:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-ipsec-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication of DHCP Relay Agent Options Using IPsec Author(s) : R. Droms Filename : draft-ietf-dhc-relay-agent-ipsec-01.txt Pages : 11 Date : 2003-11-24 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines a mechanism for securing the messages exchanged between a relay agent and a server using IPsec (RFC 2401). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-relay-agent-ipsec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-relay-agent-ipsec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-24152345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-24152345.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 24 16:36:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02178; Mon, 24 Nov 2003 16:36:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOONG-000303-Ex; Mon, 24 Nov 2003 16:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOON5-0002zQ-Co for dhcwg@optimus.ietf.org; Mon, 24 Nov 2003 16:35:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02104 for ; Mon, 24 Nov 2003 16:35:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOON3-0005Ou-00 for dhcwg@ietf.org; Mon, 24 Nov 2003 16:35:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AOON2-0005Ny-00 for dhcwg@ietf.org; Mon, 24 Nov 2003 16:35:49 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2003 13:35:14 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAOLZGw5021497 for ; Mon, 24 Nov 2003 13:35:16 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.206]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEF54779; Mon, 24 Nov 2003 16:35:15 -0500 (EST) Message-Id: <4.3.2.7.2.20031124162735.01f40b78@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Nov 2003 16:35:13 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] draft-ietf-dhc-relay-agent-ipsec-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've just published an update to "Authentication of DHCP Relay Agent Options Using IPsec" as draft-ietf-dhc-relay-agent-ipsec-01.txt. This update includes changes based on comments received during the IESG review of the document. In the interest of full disclosure, here's a summary of the changes in draft-ietf-dhc-relay-agent-ipsec-01.txt: * I've added a section 5, "Relay Agent Message Threat Model" * I've added text to the effect that the relay agents must all belong to the same administrative domain, which is normal (if not universal) practice in real deployments. As I thought about this issue, I realized that one additional IPsec session is required, between the server and A, because messages returned by the server go directly to A, bypassing B and C. Yes, that means B and C cannot add relay agent options, which is noted in RFC 3046. * I've added figure 1, showing the deployment with a single relay agent, and figure 2, showing the deployment with multiple relay agents. * Fixed misspelling of IPsec on page 4 * I've expanded the Security Considerations section, and added pointers back to the threat model. The only substantive change is in the second bullet item: the requirement that, in the case where there are multiple relay agents, there be an IPsec session from the server back to the relay agent closest to the client. Any comments on that change? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 24 21:43:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17365; Mon, 24 Nov 2003 21:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTAM-0004Vg-3Q; Mon, 24 Nov 2003 21:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOT9l-0004VE-JG for dhcwg@optimus.ietf.org; Mon, 24 Nov 2003 21:42:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17329 for ; Mon, 24 Nov 2003 21:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOT9i-0003a6-00 for dhcwg@ietf.org; Mon, 24 Nov 2003 21:42:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOT9i-0003Zj-00 for dhcwg@ietf.org; Mon, 24 Nov 2003 21:42:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 18:43:06 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAP2fow5020431 for ; Mon, 24 Nov 2003 18:41:50 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-225.cisco.com [10.82.224.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEF73386; Mon, 24 Nov 2003 21:41:48 -0500 (EST) Message-Id: <4.3.2.7.2.20031124213946.01eeb958@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Nov 2003 21:41:45 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHCPv6 assigned numbers registry Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , For those of you working on DHCPv6 implementations, the IANA registry for numbers assigned in DHCPv6 is available at http://www.iana.org/assignments/dhcpv6-parameters It includes the latest assignments for DNS configuration and PD options. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 11:44:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26339; Tue, 25 Nov 2003 11:44:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgHK-0007Ap-08; Tue, 25 Nov 2003 11:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgGp-0006xW-QS for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 11:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26218; Tue, 25 Nov 2003 11:42:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGo-0000iA-00; Tue, 25 Nov 2003 11:42:34 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGn-0000hC-00; Tue, 25 Nov 2003 11:42:33 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAPGg1g6322690; Tue, 25 Nov 2003 11:42:02 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPGg0je129326; Tue, 25 Nov 2003 11:42:00 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hAPGeboA032254; Tue, 25 Nov 2003 11:40:37 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hAPGebE2032249; Tue, 25 Nov 2003 11:40:37 -0500 Message-Id: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> To: Pete McCann cc: dhcwg@ietf.org, mip4@ietf.org In-Reply-To: Message from mccap@lucent.com of "Mon, 24 Nov 2003 14:15:49 CST." <16322.26357.232206.379182@gargle.gargle.HOWL> Date: Tue, 25 Nov 2003 11:40:37 -0500 From: Thomas Narten Subject: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is my review of this document. Note that I'm crossposting because some of my comments are more DHCP-ish, while others are MIP4-ish. Thomas > The Mobility Agent Information field shall NOT be terminated with a > 255 sub-option. The length N of the DHCP Mobility Agent Information Why is this here? There is presumably no "255 sub-option" defined, since this document definess all the suboptions that are applicable to this option. Or am I just confused? > tuples. Since at least one sub-option must be defined, the minimum > Mobility Agent Information length is two (2). The length N of the s/must be defined/must be included in the option/ > value field. A sub-option length may be zero. The sub-options need > not appear in sub-option code order. Would it be appropriate to go further and say: The sub-options need not appear in any particular order. (Just asking, I don't have a strong opinion, other than if ordering is important, now is the time to make the rules clear.) > The Network Access Identifier sub-option of the Mobility Agent > Information Option MAY be used by the DHCP client to provide > identifying information to the DHCP server, as part of the > DHCPDISCOVER message. The server may then use this information in > selecting mobility agent announcement parameters for the client. Can this sub-option only be provide in the DISCOVER, or can it also appear in the REQUEST? (I would assume both, i.e., I think clients can provide options in the REQUEST normally) > Option code > DHCP_MIP_OPTION (to be assigned by IANA) > > Length > Length in bytes of this option, not including the Option code and > Length bytes. Not sure why you include this here (section 3.3.) the picture shows only a suboption. Shouldn't the description just include the sub-option fields? (This is also for consistency, since the other suboption doesn't seem to include the code/length of DHC option itself). > The address trough which the Mobile Node may reach the announced s/trough/through/ > Sequence Number > The count of Mobility Agent DHCP announcements made since the DHCP > server was initialized (RFC 3220, Section 2.3.2 [5]). This is copied from the MIP advertisement. But does it make sense here? Isn't this for replay protection (or something?)? Not sure the same rational applies here. Also, this is a potentially significant new requirement on the DCHP server. I'm not aware of any other option that requires this sort of state me maintained. Also, what does it mean in the context of DHC, where the server may be talking to multiple different clients... Is this a per-client count, or a total count? > B > Busy. The foreign agent will not accept registrations from > additional mobile nodes. Also copied from the MIP message. But the DHC server generally won't be able to set this bit sensibly as I would assume only very loose syncronization between the DHC server and specific mobility agents. > 6. IANA Considerations > > The value for the DHCP_MIP_OPTION code must be assigned from the > numbering space defined for public DHCP Options in RFC 2939 [10]. Create a new IANA registry for future subtypes? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 12:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27259; Tue, 25 Nov 2003 12:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgba-0000Mh-Vp; Tue, 25 Nov 2003 12:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgbQ-0000Lf-VV for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 12:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27237; Tue, 25 Nov 2003 12:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbP-00016Y-00; Tue, 25 Nov 2003 12:03:51 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbO-00016T-00; Tue, 25 Nov 2003 12:03:50 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 071D81B200F; Tue, 25 Nov 2003 11:02:41 -0600 (CST) In-Reply-To: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> References: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5--869180668" Message-Id: <4ECCF485-1F69-11D8-8AC9-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mip4@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Date: Tue, 25 Nov 2003 11:03:36 -0600 To: Thomas Narten X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.606) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-5--869180668 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thomas, FYI, I think that the extra wording about ordering and end options is there because implementors sometimes (often enough that it's been an observed problem) fail to read the documents carefully, and this creates interoperability problems, so repeating things that are already obvious if one has carefully read, e.g., RFC2132, is actually constructive. We have, for example, encountered DHCP client implementations that blow up if you send the options in an unexpected order, or expect options to be padded so that multibyte values are appropriately aligned for picky architectures. Usually these implementations either don't last, or get fixed, but IMHO it's worth adding a little extra verbiage to try to nip these errors in the bud. --Apple-Mail-5--869180668 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/w4tqfAsUA+esjrARAhpAAJ4nEcDEC6NvJYNnwGS5OS0bFgpwMACePgr5 b5cfYmdxH0mel/N70XPwN58= =VjtZ -----END PGP SIGNATURE----- --Apple-Mail-5--869180668-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 12:25:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28334; Tue, 25 Nov 2003 12:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvu-0002ka-DX; Tue, 25 Nov 2003 12:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvB-0002jQ-Uj for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 12:24:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28272; Tue, 25 Nov 2003 12:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgv9-0001WB-00; Tue, 25 Nov 2003 12:24:15 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AOgv9-0001Vv-00; Tue, 25 Nov 2003 12:24:15 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAPHNcEY014286; Tue, 25 Nov 2003 18:23:38 +0100 Date: Tue, 25 Nov 2003 18:23:39 +0100 From: Henrik Levkowetz To: Thomas Narten Cc: Pete McCann , dhcwg@ietf.org, mip4@ietf.org Message-Id: <20031125182339.0664010e.henrik@levkowetz.com> In-Reply-To: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> References: <16322.26357.232206.379182@gargle.gargle.HOWL> <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thank you, Thomas. Comments below. /Henrik On Tuesday, 25 Nov 2003, Thomas wrote: > Here is my review of this document. Note that I'm crossposting because > some of my comments are more DHCP-ish, while others are MIP4-ish. > > Thomas > > > The Mobility Agent Information field shall NOT be terminated with a > > 255 sub-option. The length N of the DHCP Mobility Agent Information > > Why is this here? There is presumably no "255 sub-option" defined, > since this document definess all the suboptions that are applicable to > this option. Or am I just confused? I doubt the latter :-) I included this here as there exists an 255 end option (not sub-option) which seems to have prompted the same clarifying (or confusing!) text in some other documents defining suboptions. It doesn't seem needed, but maybe there is history lurking here? > > > tuples. Since at least one sub-option must be defined, the minimum > > Mobility Agent Information length is two (2). The length N of the > > s/must be defined/must be included in the option/ Yes. > > value field. A sub-option length may be zero. The sub-options need > > not appear in sub-option code order. > > Would it be appropriate to go further and say: > > The sub-options need not appear in any particular order. Yes. And (as urged by other people on the dhcwg list) I'll change the zero length part to require a flag instead of using the option presence itself as a flag. > > The Network Access Identifier sub-option of the Mobility Agent > > Information Option MAY be used by the DHCP client to provide > > identifying information to the DHCP server, as part of the > > DHCPDISCOVER message. The server may then use this information in > > selecting mobility agent announcement parameters for the client. > > Can this sub-option only be provide in the DISCOVER, or can it also > appear in the REQUEST? (I would assume both, i.e., I think clients can > provide options in the REQUEST normally) Both make sense to me. Will rectify. > > Option code > > DHCP_MIP_OPTION (to be assigned by IANA) > > > > Length > > Length in bytes of this option, not including the Option code and > > Length bytes. > > Not sure why you include this here (section 3.3.) the picture shows > only a suboption. Shouldn't the description just include the > sub-option fields? (This is also for consistency, since the other > suboption doesn't seem to include the code/length of DHC option > itself). Yes. should be sub-option, not option. > > The address trough which the Mobile Node may reach the announced > > s/trough/through/ Yes. > > Sequence Number > > The count of Mobility Agent DHCP announcements made since the DHCP > > server was initialized (RFC 3220, Section 2.3.2 [5]). > > This is copied from the MIP advertisement. But does it make sense > here? Isn't this for replay protection (or something?)? Not sure the > same rational applies here. Also, this is a potentially significant > new requirement on the DCHP server. I'm not aware of any other option > that requires this sort of state me maintained. There are instances where the use of this field would make sense, mostly to signal a re-boot of a box with co-located dhcp server and fa. But in most cases, it should be possible to signal that this field should be ignored. My thought is to add a bit field whereby this and any other selected field may be marked "to be ignored". > Also, what does it mean in the context of DHC, where the server may be > talking to multiple different clients... Is this a per-client count, > or a total count? Total count, not per client. > > B > > Busy. The foreign agent will not accept registrations from > > additional mobile nodes. > > Also copied from the MIP message. But the DHC server generally won't > be able to set this bit sensibly as I would assume only very loose > syncronization between the DHC server and specific mobility agents. Agree; basically the same comment applies here as above for the sequence number. > > 6. IANA Considerations > > > > The value for the DHCP_MIP_OPTION code must be assigned from the > > numbering space defined for public DHCP Options in RFC 2939 [10]. > > Create a new IANA registry for future subtypes? Yes. --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/w5AbeVhrtTJkXCMRAhIlAJ4mjqOq7rISXKUCSUC89a63002aYgCgjDpR YnVMFDP+6PQc6UIJJMTgYO0= =vqxC -----END PGP SIGNATURE----- --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 15:13:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06674; Tue, 25 Nov 2003 15:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjYR-00050V-3V; Tue, 25 Nov 2003 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjAB-00033M-Pi for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 14:47:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04802; Tue, 25 Nov 2003 14:47:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjA8-00043m-00; Tue, 25 Nov 2003 14:47:52 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjA8-000430-00; Tue, 25 Nov 2003 14:47:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2003 11:48:56 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAPJlBw7003613; Tue, 25 Nov 2003 11:47:19 -0800 (PST) Received: from cisco.com (jharper-w2k.cisco.com [128.107.163.44]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANX50536; Tue, 25 Nov 2003 11:47:10 -0800 (PST) Message-ID: <3FC3B1BD.60506@cisco.com> Date: Tue, 25 Nov 2003 11:47:09 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org, henrik@levkowetz.com, dhcwg@ietf.org References: <16322.26357.232206.379182@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete, Henrik - I have a few comments/questions regarding the draft -- 1. Looks like the option (along with the sub-options) can be used in both discover/request and reply (DHCP) messages. Can you add text to clarify this? 2. How do you suggest the DHC server use the NAI? Is any form of interpretation recommended? 3. What happens when the Mobile is from a different domain and so the DHCP server cannot understand the realm in the NAI. (Related to #2 above). 4. Would it be helpful to tie the NAI with the ci_addr field? This way, when some other client makes a DHCP request using the ci_addr field (and not the mobility option with NAI suboption), DHC server can do some co-relation? I say this because I think ci_addr is a well understood/implemented option. 5. RFC 3118 (I haven't read it in detail) specifies mechanism to authenticate DHC messages. THe security section mentions that this is one advantage of using agent advertisements from DHC as opposed to FA as from 3344. My question is, what if the MN is roaming in the foreign domain? How are keys distributed to authenticate the signature (authenticator field)? Isn't that the reason the FA advertisements are not authenticated? 6. Since FA/DHC servers are supposed to be autonomous entities (running on same or different boxes), how does the DHC server keep track of the availability/loading conditions at the FA (especially if they are separate boxes)? 7. Also, as Thomas suggested, I would like to have text clarifying that further sub-options may be added. Thanks Alpesh Pete McCann wrote: >Hi, > >The MIP4 workgroup has received a query from the DHC workgroup regarding >the draft draft-ietf-dhc-mipadvert-opt-01.txt. The viewpoint of the MIP4 >working group is needed in order to advance or retire this document. >Responses are needed before 1700 EST on Thursday November 27th. > >The WG last call on this document was announced before the Minneapolis >meeting, on both the DHC list and the MIP4 list. There were responses >on the DHC list, but none on the MIP4 list. We therefore again ask for >input from the MIP4 workgroup. > >Please respond to this query. If you support acceptance of the document >without change, respond with a simple acknowledgment, so that support >for the document can be assessed. Please respond at the latest before >1700 EST on Thursday November 27th. > >draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the >Mobility Agent Option, and two sub-options of the Mobility Agent Option: the >Network Access Identifier Sub-Option, which provides >identifying information about a DHCP client to the DHCP server and the >Mobility Agent Announcement sub-option, which announces the address of one >or more mobility agents available to a host. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > > >-Pete > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 15:27:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07790; Tue, 25 Nov 2003 15:27:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjlh-00068P-MF; Tue, 25 Nov 2003 15:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkL-0005sC-IG for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 15:25:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07477; Tue, 25 Nov 2003 15:25:03 -0500 (EST) Message-Id: <200311252025.PAA07477@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Nov 2003 15:25:03 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-sntp-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Simple Network Time Protocol Configuration Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-sntp-00.txt Pages : 4 Date : 2003-11-25 This document describes a new DHCPv6 option for passing a list of SNTP server addresses to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-sntp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-25151701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-sntp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25151701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 16:13:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07789; Tue, 25 Nov 2003 15:27:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjlr-00069L-2a; Tue, 25 Nov 2003 15:26:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkQ-0005sX-2u for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 15:25:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07495; Tue, 25 Nov 2003 15:25:08 -0500 (EST) Message-Id: <200311252025.PAA07495@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Nov 2003 15:25:07 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Timezone Specifier Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-tz-00.txt Pages : 6 Date : 2003-11-25 This document describes a new DHCPv6 option for passing the client's timezone information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-tz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-25151716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-tz-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25151716.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 17:15:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13847; Tue, 25 Nov 2003 17:15:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlSY-0005Hi-S2; Tue, 25 Nov 2003 17:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlS0-0005Gf-Dc for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 17:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13787 for ; Tue, 25 Nov 2003 17:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlRy-0000KA-00 for dhcwg@ietf.org; Tue, 25 Nov 2003 17:14:26 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AOlRx-0000Ig-00 for dhcwg@ietf.org; Tue, 25 Nov 2003 17:14:25 -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 hAPMDtpI008181 for ; Tue, 25 Nov 2003 23:13:55 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAPMDsR7032504 for ; Tue, 25 Nov 2003 23:13:54 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAPMDs8k032503 for dhcwg@ietf.org; Tue, 25 Nov 2003 23:13:54 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 25 Nov 2003 23:13:54 +0100 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20031125221354.GA32492@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dhcwg] draft-venaas-dhc-lifetime-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've now submitted an updated draft, trying to address the comments I got. The content should be much more complete now. More comments welcome. Abstract: This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server to update its configuration. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 25 21:55:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22745; Tue, 25 Nov 2003 21:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOppV-00033m-GI; Tue, 25 Nov 2003 21:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOpoc-00032L-6p for dhcwg@optimus.ietf.org; Tue, 25 Nov 2003 21:54:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22681 for ; Tue, 25 Nov 2003 21:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOpoZ-0005Ke-00 for dhcwg@ietf.org; Tue, 25 Nov 2003 21:54:03 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AOpoU-0005KP-00 for dhcwg@ietf.org; Tue, 25 Nov 2003 21:54:02 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id 623A51C01430 for ; Tue, 25 Nov 2003 21:53:53 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id IAA00543 for ; Wed, 26 Nov 2003 08:22:35 +0530 (IST) Message-ID: <3FC415B3.7020203@india.hp.com> Date: Wed, 26 Nov 2003 08:23:39 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DHCPWG Content-Type: multipart/mixed; boundary="------------090305000607060109010600" Subject: [dhcwg] [Fwd: I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------090305000607060109010600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The related drafts are: http://www.ietf.org/internet-drafts/draft-vijay-ipv6-icmp-refresh-otherconf-00.txt http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt Please go through these drafts and let me know your comments Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ --------------090305000607060109010600 Content-Type: message/rfc822; name="I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt" Received: from fakir.india.hp.com (root@fakir.india.hp.com [15.10.40.3]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA08463; Wed, 26 Nov 2003 02:33:59 +0530 (IST) Received: from palrel11.hp.com (palrel11.hp.com [15.81.168.21]) by fakir.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id CAA03518; Wed, 26 Nov 2003 02:49:43 +0530 (IST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by palrel11.hp.com (Postfix) with ESMTP id C2CAB1C01ECC; Tue, 25 Nov 2003 13:05:10 -0800 (PST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AOjlZ-0007jr-8o for ietf-announce-list@asgard.ietf.org; Tue, 25 Nov 2003 15:26:33 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AOjkq-0007gY-RY for all-ietf@asgard.ietf.org; Tue, 25 Nov 2003 15:25:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07592 for ; Tue, 25 Nov 2003 15:25:35 -0500 (EST) Message-Id: <200311252025.PAA07592@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt Date: Tue, 25 Nov 2003 15:25:34 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Reconfiguration Protocol for Stateless DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt Pages : 8 Date : 2003-11-25 Stateless DHCPv6 [DHCPv6Light] is a light-weight DHCPv6 [DHCPv6] protocol in which the server manages only the service parameters like DNS server addresses, NTP server addresses etc., and hence there is no need to maintain the state of the clients, perhaps, it doesn't need to store any information about the clients at all. So, a renumbering event or change in some of the configuration parameters cannot be notified to the clients by the stateless DHCPv6 server. This specification provides a solution for this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-25151842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25151842.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------090305000607060109010600-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 26 07:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04122; Wed, 26 Nov 2003 07:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOyl3-0006JK-RF; Wed, 26 Nov 2003 07:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOykp-0006I1-Lv for dhcwg@optimus.ietf.org; Wed, 26 Nov 2003 07:26:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04100 for ; Wed, 26 Nov 2003 07:26:34 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOykp-0004a7-00 for dhcwg@ietf.org; Wed, 26 Nov 2003 07:26:47 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137] helo=i2kc01-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AOyko-0004Zf-00 for dhcwg@ietf.org; Wed, 26 Nov 2003 07:26:46 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:26:15 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:26:15 +0000 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 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] [Fwd: I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] Date: Wed, 26 Nov 2003 12:25:30 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7003EFEB30@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] [Fwd: I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] Thread-Index: AcOzyMnLAY86V9gnTwmLTvNAzMhxcQATykTA To: Cc: X-OriginalArrivalTime: 26 Nov 2003 12:26:15.0694 (UTC) FILETIME=[7C77B2E0:01C3B418] Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Vijay,=20 > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]=20 > Sent: 26 November 2003 02:54 > To: DHCPWG > Subject: [dhcwg] [Fwd: I-D=20 > ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] >=20 > The related drafts are: >=20 > http://www.ietf.org/internet-drafts/draft-vijay-ipv6-icmp-refr > esh-otherconf-00.txt Extending ND is not a very elegant solution to this problem in my opinion, and very unlikely to gain wide acceptance. Extensions to DHCPv6 are the best way to solve this host configuration problem. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 27 12:44:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13624; Thu, 27 Nov 2003 12:44:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQBN-0003ty-46; Thu, 27 Nov 2003 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQAj-0003t9-Bq for dhcwg@optimus.ietf.org; Thu, 27 Nov 2003 12:43:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13575 for ; Thu, 27 Nov 2003 12:43:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APQAh-000369-00 for dhcwg@ietf.org; Thu, 27 Nov 2003 12:43:19 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1APQAg-00035L-00 for dhcwg@ietf.org; Thu, 27 Nov 2003 12:43:19 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1APQAC-00076h-00 for ; Thu, 27 Nov 2003 09:42:48 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5ZGLL>; Thu, 27 Nov 2003 09:42:40 -0800 Message-ID: From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Thu, 27 Nov 2003 09:42:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B50D.D818EBA0" Subject: [dhcwg] draft-ietf-dhc-leasequery-06 clarification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3B50D.D818EBA0 Content-Type: text/plain; charset="iso-8859-1" I think that the draft has a potential ambiguity in handling option 82 in the leasequery replies. RFC 3046 mandates that option 82 SHOULD be the last option in the reply packet. The leasequery draft only says that it will be included in the packet if the relay requested option 82 (and assuming that the DHCP server has information to put in option 82). So, from a leasequery perspective, if the server has data to put in option 82, where should the draft specify that the option should be placed within the packet? Should it also specify that option 82 SHOULD be the last option within the packet, and may not be placed in the overloaded fields? Or should the draft specify that option 82 within the leasequery reply may be anywhere within the options field? My opinion on the matter: I think that the presence of option 82 within a leasequery reply serves a different purpose that the presence of option 82 within a "normal" DHCP reply. Within a normal reply, option 82 needs to be able to be removed by the Relay without potentially disrupting any 3118 authentication that may be in use. Also option 82 may be carrying some sort of "routing" information for where this reply is really destined for (which circuit ID, which remote ID, etc). However in a leasequery reply the presence of option 82 is simply "dead data" that is being passed from the DHCP server to the relay. It has no more significance within the packet than the presence of, say, option 3. Given these points, I would suggest that the draft specify that the option 82 inserted in a leasequery reply does not have to follow the rules of 3046, but is to be handled like any other option (order & positioning is irrelevant, it may be placed in overloads, etc...). And come to think of it, another wrinkle within this mechanism: what would be the correct behaviour for a DHCP server which receives a leasequery that has an option 82? According to 3046, the DHCP server would be required to echo it back to the client, but that would overwrite (or append to) the existing option 82 (which is the one that was being sent back as part of the leasequery reply). Should the draft specify that a relay MUST NOT supply an option 82 in its leasequery? ------_=_NextPart_001_01C3B50D.D818EBA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-dhc-leasequery-06 clarification

I think that the draft has a potential ambiguity in = handling option 82 in the leasequery replies.

RFC 3046 mandates that option 82 SHOULD be the last = option in the reply packet.  The leasequery draft only says that = it will be included in the packet if the relay requested option 82 (and = assuming that the DHCP server has information to put in option = 82).

So, from a leasequery perspective, if the server has = data to put in option 82, where should the draft specify that the = option should be placed within the packet?  Should it also specify = that option 82 SHOULD be the last option within the packet, and may not = be placed in the overloaded fields?  Or should the draft specify = that option 82 within the leasequery reply may be anywhere within the = options field?

My opinion on the matter: I think that the presence = of option 82 within a leasequery reply serves a different purpose that = the presence of option 82 within a "normal" DHCP reply.  = Within a normal reply, option 82 needs to be able to be removed by the = Relay without potentially disrupting any 3118 authentication that may = be in use.  Also option 82 may be carrying some sort of = "routing" information for where this reply is really destined = for (which circuit ID, which remote ID, etc).  However in a = leasequery reply the presence of option 82 is simply "dead = data" that is being passed from the DHCP server to the = relay.  It has no more significance within the packet than the = presence of, say, option 3.  Given these points, I would suggest = that the draft specify that the option 82 inserted in a leasequery = reply does not have to follow the rules of 3046, but is to be handled = like any other option (order & positioning is irrelevant, it may be = placed in overloads, etc...).

And come to think of it, another wrinkle within this = mechanism: what would be the correct behaviour for a DHCP server which = receives a leasequery that has an option 82?  According to 3046, = the DHCP server would be required to echo it back to the client, but = that would overwrite (or append to) the existing option 82 (which is = the one that was being sent back as part of the leasequery = reply).  Should the draft specify that a relay MUST NOT supply an = option 82 in its leasequery?

------_=_NextPart_001_01C3B50D.D818EBA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 27 12:54:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13843; Thu, 27 Nov 2003 12:54:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQL4-0004Xo-0m; Thu, 27 Nov 2003 12:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQKN-0004UQ-3b for dhcwg@optimus.ietf.org; Thu, 27 Nov 2003 12:53:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13834 for ; Thu, 27 Nov 2003 12:53:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APQKL-0003Dp-00 for dhcwg@ietf.org; Thu, 27 Nov 2003 12:53:17 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1APQKK-0003Dm-00 for dhcwg@ietf.org; Thu, 27 Nov 2003 12:53:16 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id AF9E21C019CE; Thu, 27 Nov 2003 12:53:14 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id XAA12333; Thu, 27 Nov 2003 23:21:56 +0530 (IST) Message-ID: <3FC63A06.9090404@india.hp.com> Date: Thu, 27 Nov 2003 23:23:10 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: matthew.ford@bt.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [Fwd: I-D ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] References: <0AAF93247C75E3408638B965DEE11A7003EFEB30@i2km41-ukdy.domain1.systemhost.net> In-Reply-To: <0AAF93247C75E3408638B965DEE11A7003EFEB30@i2km41-ukdy.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mat, I really don't see any problem in extending ND for this.. Perhaps, it is better than extending ND for doing service discovery, as certainly it is not intended for that.... When the routers notify the nodes to use dhcpv6 for service discovery (O bit) and notify the nodes with change in the prefix(through RAs), i guess, RAs can be used for notifying the change in service parameters also.... Did you find any flaw in this model, which will hinder the normal working of ND? Vijay matthew.ford@bt.com wrote: >Vijay, > > > >>-----Original Message----- >>From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] >>Sent: 26 November 2003 02:54 >>To: DHCPWG >>Subject: [dhcwg] [Fwd: I-D >>ACTION:draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt] >> >>The related drafts are: >> >>http://www.ietf.org/internet-drafts/draft-vijay-ipv6-icmp-refr >>esh-otherconf-00.txt >> >> > >Extending ND is not a very elegant solution to this problem in my >opinion, and very unlikely to gain wide acceptance. Extensions to DHCPv6 >are the best way to solve this host configuration problem. > >Mat > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 28 15:39:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10659; Fri, 28 Nov 2003 15:39:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APpOG-0004Sm-Mr; Fri, 28 Nov 2003 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APpNK-0004OI-Ra for dhcwg@optimus.ietf.org; Fri, 28 Nov 2003 15:38:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10592 for ; Fri, 28 Nov 2003 15:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APpNI-00017i-00 for dhcwg@ietf.org; Fri, 28 Nov 2003 15:38:00 -0500 Received: from smtp003.mail.ukl.yahoo.com ([217.12.11.34]) by ietf-mx with smtp (Exim 4.12) id 1APpNI-00015x-00 for dhcwg@ietf.org; Fri, 28 Nov 2003 15:38:00 -0500 Received: from adsl-64-169-90-78.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.90.78 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 28 Nov 2003 20:37:28 -0000 Reply-To: From: "Barr Hibbs" To: , Cc: "Dhcwg" Date: Fri, 28 Nov 2003 12:38:07 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3FBCE1C5.B7E2A99D@alcatel.be> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: draft-ietf-dhc-server-mib-08 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit comments in-line --Barr > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > Sent: Thursday, November 20, 2003 07:46 > > I have a question on draft-ietf-dhc-server-mib-08: > > 1) In the SharedNetTable and the SubnetTable, I see low and > high tresholds. Is this not redundant? > ...no, this is to prevent hysteresis, or constant "on/off" notifications while the value of free addresses hovers around a single threshold value. > Also in the notifications, I only see those of the SharedNetTable > and not those of the SubnetTable. > ...because a shared network segment can be composed of multiple subnetworks, we felt that a notification was necessary only if the shared network segment free address counter passed through the low and high threshold point. > 2) Should such thresholds also be added in the RangeTable? > ...no, because the RangeTable describes a subdivision of a subnet, and we felt that it was appropriate to only trigger notifications at the subnet level. > 3) last word in the description of the high theshold: events > will be generated again when the number of available > addresses becomes equal to or less than the value of the > *low* threshold, while the draft says *high* threshold. > ...good catch! Note to Glenn: the draft I just sent for your concurrence is lacking this change, but will be included when I submit the draft to the I-D editor, hopefully Monday. --rbh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg