From owner-dhcp-v4@bucknell.edu Fri Dec 1 06:33:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26460 for ; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1BTJO10968; Fri, 1 Dec 2000 06:29:19 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1BT5O03033 for ; Fri, 1 Dec 2000 06:29:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23212; Fri, 1 Dec 2000 06:29:04 -0500 (EST) Message-Id: <200012011129.GAA23212@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-packetcable-01.txt Date: Fri, 01 Dec 2000 06:29:03 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for PacketCable VoIP Client Configuration Author(s) : B. Beser Filename : draft-ietf-dhc-packetcable-01.txt Pages : 7 Date : 30-Nov-00 The Voice over IP work carried over in the PacketCable project conducted by CableLabs. The configuration of the PacketCable Voice over IP client is achieved using DHCP messaging. This document contains the definition of PacketCable VoIP Client configuration option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-packetcable-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-packetcable-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: <20001130114152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114152.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Fri Dec 1 10:20:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20329; Fri, 1 Dec 2000 10:20:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1FHJO23833; Fri, 1 Dec 2000 10:17:19 -0500 (EST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1FH4O15814 for ; Fri, 1 Dec 2000 10:17:05 -0500 (EST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id E6A5F73E3; Fri, 1 Dec 2000 07:16:55 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 697A875AE for ; Fri, 1 Dec 2000 07:16:55 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000690048; Fri, 1 Dec 2000 10:16:30 -0500 (EST) From: Jim Bound Message-Id: <200012011516.KAA0000690048@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: -16 rev of DHCPv6 spec In-reply-to: Your message of "Tue, 28 Nov 2000 10:36:09 EST." <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Date: Fri, 01 Dec 2000 10:16:30 -0500 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Bernie, Thanks for the careful read and great input. I am traveling alot this week again so can't respond in details but talking with Ralph and Mike consistently. But do want to suggest a response to one of your points. Can discuss further on design tele conference next week. >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > >>From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ If I understand what your suggesting?, we cannot do what you ask. The reason is that we cannot assume in any IETF protocol the "interface ID" will always be 64bytes for all RFC 2373 prefixes. I thought this to some years ago as I wanted to only carry 64byte prefixes in our internal OS inpcb structures for IPv6 in the kernel for fast lookups and for host routing path search. But, then I would have to have if-condition construct for the Format-Prefix for IPv6 addresses. See below from RFC 2373: --------------------------- 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same as that interface's link- layer address. The same interface identifier may be used on multiple interfaces on a single node. Note that the use of the same interface identifier on multiple interfaces of a single node does not affect the interface identifier's global uniqueness or each IPv6 addresses global uniqueness created using that interface identifier. In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. EUI-64 based Interface identifiers may have global scope when a global token is available (e.g., IEEE 48bit MAC) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be inverted when forming the interface identifier from the EUI-64. The "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an EUI-64 identifier are as follows: 0 0 0 1 1 2 |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+ ----------------------------------------------- The key is the sentence in the above paragraph first sentence "In a number of format prefixes"......Not all IPv6 Format Prefixes will have just 64byte interface ids. Does this resolve your suggestion? thanks /jim From owner-dhcp-v6@bucknell.edu Fri Dec 1 11:14:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03976; Fri, 1 Dec 2000 11:14:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1GBVO15436; Fri, 1 Dec 2000 11:11:31 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1GBHO06197 for ; Fri, 1 Dec 2000 11:11:17 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 11:11:02 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8603607458@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Fri, 1 Dec 2000 11:11:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jim: Yes I think it does clearly resolve the issue (use all 128 bits). - Bernie -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Friday, December 01, 2000 10:17 AM To: DHCPv6 discussion list Cc: bound@zk3.dec.com Subject: Re: -16 rev of DHCPv6 spec Hi Bernie, Thanks for the careful read and great input. I am traveling alot this week again so can't respond in details but talking with Ralph and Mike consistently. But do want to suggest a response to one of your points. Can discuss further on design tele conference next week. >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > >>From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ If I understand what your suggesting?, we cannot do what you ask. The reason is that we cannot assume in any IETF protocol the "interface ID" will always be 64bytes for all RFC 2373 prefixes. I thought this to some years ago as I wanted to only carry 64byte prefixes in our internal OS inpcb structures for IPv6 in the kernel for fast lookups and for host routing path search. But, then I would have to have if-condition construct for the Format-Prefix for IPv6 addresses. See below from RFC 2373: --------------------------- 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same as that interface's link- layer address. The same interface identifier may be used on multiple interfaces on a single node. Note that the use of the same interface identifier on multiple interfaces of a single node does not affect the interface identifier's global uniqueness or each IPv6 addresses global uniqueness created using that interface identifier. In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. EUI-64 based Interface identifiers may have global scope when a global token is available (e.g., IEEE 48bit MAC) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be inverted when forming the interface identifier from the EUI-64. The "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an EUI-64 identifier are as follows: 0 0 0 1 1 2 |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+ ----------------------------------------------- The key is the sentence in the above paragraph first sentence "In a number of format prefixes"......Not all IPv6 Format Prefixes will have just 64byte interface ids. Does this resolve your suggestion? thanks /jim From owner-dhcp-v6@bucknell.edu Fri Dec 1 14:57:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06825; Fri, 1 Dec 2000 14:57:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB1JbRO21298; Fri, 1 Dec 2000 14:37:27 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB1JbCO31749 for ; Fri, 1 Dec 2000 14:37:12 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27014 for ; Fri, 1 Dec 2000 11:37:02 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB1Jb7327021 for ; Fri, 1 Dec 2000 11:37:07 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03253 for ; Fri, 1 Dec 2000 11:36:53 -0800 (PST) Message-Id: <4.3.1.2.20001201143050.00b104f0@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Dec 2000 14:36:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Design team teleconference - last call for participation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have scheduled another design team teleconference for 12/5, 12noon-3PM EST. The purpose of this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. You can get more information about the -16 rev and the teleconference at http://www.dhcp.org/dhcpv6-stat.html Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. I will be travelling Monday and may not be able to answer last minute requests to join the teleconference, so please contact me today if you haven't already done so. - Ralph From owner-dhcp-v4@bucknell.edu Mon Dec 4 04:44:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07975 for ; Mon, 4 Dec 2000 04:44:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB49deO02135; Mon, 4 Dec 2000 04:39:41 -0500 (EST) Received: from correu.urv.es (correu.urv.es [193.144.16.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB49dSO31732 for ; Mon, 4 Dec 2000 04:39:28 -0500 (EST) Received: from angel-1.urv.es (anrr.si.urv.es) by correu.urv.es (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0G5100FGRETQZ3@correu.urv.es> for dhcp-v4@bucknell.edu; Mon, 4 Dec 2000 10:39:27 +0100 (MET) Date: Mon, 04 Dec 2000 10:39:26 +0100 From: Angel Ramon Subject: A problem with Samba X-Sender: anrr@correu.urv.es To: DHCPv4 discussion list Message-id: <5.0.0.25.1.20001204103309.009d41c0@correu.urv.es> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Content-type: text/plain; format=flowed; charset=us-ascii Reply-To: anrr@correu.urv.es Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, list. In my organization we are running a Samba server 2.0.7 in a Solaris 8 box. It was working well, but two weeks ago we changed from static ip's to dhcp, and since then we have problems to find the Samba server. The wins server IP is given by the DHCP server, and when the windows 9x clients start they get their address but can't reach the samba server, and can't connect to samba shares automatically. It's a big problem, becouse users don't know how to connect to the shares manually. If we change to static wins server, the problem disappears. Have you any idea? Please help me!!! From owner-dhcp-v6@bucknell.edu Tue Dec 5 04:23:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09687; Tue, 5 Dec 2000 04:23:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB59JZO02846; Tue, 5 Dec 2000 04:19:35 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB59JQO24305 for ; Tue, 5 Dec 2000 04:19:26 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id 9BA01E95 for ; Tue, 5 Dec 2000 01:19:23 -0800 (PST) Received: from india.hp.com (vijayak@dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id OAA06792 for ; Tue, 5 Dec 2000 14:47:53 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3A2CB373.2FDFC2E8@india.hp.com> Date: Tue, 05 Dec 2000 14:50:52 +0530 From: vijaya bhaskar Organization: hp ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: DHCPv6 Issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: vijayak@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello Ralph, My name is Vijay. I am working with Hewlett-Packard India in HP-UX lab. I am working on DHCP. I, along with my colleague Jitesh, will be attending to the teleconf. We have the following implementation issues : 1. What would happen if there are multiple relays present in the same link and all of them transmit packets from the same server? Would there be a problem currently? 2. By what mechanism will the client talk to the application layer? 3. What authentiactions needs to be supported? What happens if the client supports it and the server does not? Could you please include these issues in the discussion? Thanks & regards, Vijay. From owner-dhcp-v6@bucknell.edu Wed Dec 6 07:19:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22354; Wed, 6 Dec 2000 07:19:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB6CDcO04610; Wed, 6 Dec 2000 07:13:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB6CDMO16324; Wed, 6 Dec 2000 07:13:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA18916; Wed, 6 Dec 2000 04:13:09 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB6CDIt23754; Wed, 6 Dec 2000 04:13:18 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA27115; Wed, 6 Dec 2000 04:13:05 -0800 (PST) Message-Id: <4.3.1.2.20001206070946.00c41d50@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 07:12:58 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Updated agendas for DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN FYI (also available at http://www.dhcp.org/0012-meeting.html with links to I-Ds)... ===== 12/11, 0900-1130 - DHCPv4 agenda items -------------------------------------- DHC WG activities update Ralph Droms, 15 minutes DHCP Option for PacketCable Burcak Beser, 15 minutes VoIP Client Configuration DHCP failover protocol Kim Kinnear, 15 minutes DHCP Lease Query Kim Kinnear, 15 minutes Addition of Device Class Rich Woundy, 15 minutes to Agent Options Dynamic Host Configuration Barr Hibbs, 10 minutes Protocol (DHCP) Server MIB DHC Load Balancing Algorithm Bernie Volz, 10 minutes The Classless Static Route Ted Lemon, 15 minutes Option for DHCP DHCP Domain Search Option Bernard Aboba, 15 minutes 12/12, 0900-1130 - DHCPv6 spec review ------------------------------------- Dynamic Host Configuration Mike Carney Protocol for IPv6 (DHCPv6) Jim Bound Charlie Perkins Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Dec 6 07:19:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22467 for ; Wed, 6 Dec 2000 07:19:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB6CDcO02955; Wed, 6 Dec 2000 07:13:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB6CDMO16324; Wed, 6 Dec 2000 07:13:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA18916; Wed, 6 Dec 2000 04:13:09 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB6CDIt23754; Wed, 6 Dec 2000 04:13:18 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA27115; Wed, 6 Dec 2000 04:13:05 -0800 (PST) Message-Id: <4.3.1.2.20001206070946.00c41d50@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 07:12:58 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Updated agendas for DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN FYI (also available at http://www.dhcp.org/0012-meeting.html with links to I-Ds)... ===== 12/11, 0900-1130 - DHCPv4 agenda items -------------------------------------- DHC WG activities update Ralph Droms, 15 minutes DHCP Option for PacketCable Burcak Beser, 15 minutes VoIP Client Configuration DHCP failover protocol Kim Kinnear, 15 minutes DHCP Lease Query Kim Kinnear, 15 minutes Addition of Device Class Rich Woundy, 15 minutes to Agent Options Dynamic Host Configuration Barr Hibbs, 10 minutes Protocol (DHCP) Server MIB DHC Load Balancing Algorithm Bernie Volz, 10 minutes The Classless Static Route Ted Lemon, 15 minutes Option for DHCP DHCP Domain Search Option Bernard Aboba, 15 minutes 12/12, 0900-1130 - DHCPv6 spec review ------------------------------------- Dynamic Host Configuration Mike Carney Protocol for IPv6 (DHCPv6) Jim Bound Charlie Perkins Ralph Droms From owner-dhcp-v6@bucknell.edu Wed Dec 6 12:58:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02010; Wed, 6 Dec 2000 12:58:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB6HrrO01793; Wed, 6 Dec 2000 12:53:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB6HrjO09801 for ; Wed, 6 Dec 2000 12:53:45 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA19516 for ; Wed, 6 Dec 2000 12:53:27 -0500 (EST) Message-Id: <4.3.1.2.20001206124002.00c44100@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 12:53:41 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: WG meeting, 12/12 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN If you plan to attend next week's WG meeting... The -16 rev of the DHCPv6 spec is *significantly* different from the -15 rev. One major change is that the spec is currently documented in a single I-D, http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-16.txt The changes in rev -16 are summarized in section 23. The WG members contributing to the draft have held two teleconferences since the last WG meeting in Pittsburgh. During the first teleconference, we generated a list of issues that were addressed in the most recent rev of the I-D. In the second teleconference (on 12/5), we reviewed some remaining issues from the -16 draft and developed a list of issues to bring to the WG. Summaries of those meetings are available at http://www.dhcp.org You *must* read the -16 rev of the draft before contributing to the WG discussion next Tuesday. We will move *very* fast through the changes in the -16 draft and the issues discussed in the 12/5 teleconference, to gauge WG consensus on the draft and proposed solutions to some outstanding issues. We will also discuss a couple of outstanding issues - most notably the design and use of UUIDs and the options to be included in the base spec I-D. - Ralph From owner-dhcp-v6@bucknell.edu Fri Dec 8 11:34:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07916; Fri, 8 Dec 2000 11:34:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB8GU0O11283; Fri, 8 Dec 2000 11:30:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB8GToO05967 for ; Fri, 8 Dec 2000 11:29:50 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20937 for ; Fri, 8 Dec 2000 11:29:34 -0500 (EST) Message-Id: <4.3.1.2.20001208112719.00b31e40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 08 Dec 2000 11:29:50 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Agenda preview Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Look at http://www.dhcp.org/DHCPv6-slides/index.html to preview the slides from the DHC WG meeting on DHCPv6 scheduled for next Tuesday, 12/12. We're going to go through the slides from the 8/31 teleconference quickly, so you'll have a better chance of keeping up if you can review those slides before the 12/12 meeting... - Ralph Droms From owner-dhcp-v6@bucknell.edu Fri Dec 8 16:03:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24672; Fri, 8 Dec 2000 16:03:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eB8KxbO03891; Fri, 8 Dec 2000 15:59:37 -0500 (EST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eB8KxIO03779 for ; Fri, 8 Dec 2000 15:59:18 -0500 (EST) Received: by alfa.itea.ntnu.no id VAA0000015593; Fri, 8 Dec 2000 21:59:16 +0100 (MET) From: Stig Venås Date: Fri, 8 Dec 2000 21:59:16 +0100 To: DHCPv6 discussion list Subject: Re: -16 rev of DHCPv6 spec Message-ID: <20001208215916.A20355@itea.ntnu.no> References: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com>; from Volz@ipworks.com on Tue, Nov 28, 2000 at 10:36:09AM -0500 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've finally read the draft and have some comments as well. On Tue, Nov 28, 2000 at 10:36:09AM -0500, Bernie Volz wrote: > Ralph and others ... here's some comments on the -16 spec. > > In general, this looks GREAT! Excellent job! Yes > - Section 22.2's diagram has a "pref. len". Yet this field is not defined > anywhere in the list of fields. Was this an error in the diagram? Or was > this to be the "prefix length"? If pref. len is prefix length, you might > want to consider what to use as an abbreviation since then pref. could be > "prefix" or "preferred" (as in preferred lifetime). I think it must be prefix len, but I agree, the abbreviation is no good. > - In section 10.3.3, there are several mentions of "advertising availability > of IP address" ... how is this done (perhaps there will or is an option that > will provide this information?). Also, if this capability DOES exist, isn't > Ted's Discussion point in section 10.5.2 null and void? My thought too. I think such an option is a good idea, but it requires an option not specified in the draft as I understand it. One more thing. It says several places that an IA is identified by (prefix, UUID), why isn't the UUID enough? The 64 bits UUID should be enough on it's own I would think. There are also situations where I don't understand how the server knows the prefix, I think things would be much simpler if the UUID were enough on it's own. In order to do this, the IA UUID would have to be decided by the server though, or one has to make sure two clients won't use the same UUID in requests to the same server. If one uses (prefix, UUID) the server must always know the prefix when it gets an IA (don't think this is the case now), and one must also make sure two clients won't try to use same (prefix, UUID) pair. I haven't had time to think about all the details yet, my apologies if I have missed something vital. Stig From owner-dhcp-v6@bucknell.edu Mon Dec 11 01:35:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22830; Mon, 11 Dec 2000 01:35:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBB6V4929261; Mon, 11 Dec 2000 01:31:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBB6Up904585 for ; Mon, 11 Dec 2000 01:30:51 -0500 (EST) Received: from rdroms-nt.cisco.com (rtp-vpn-28.cisco.com [10.82.192.28]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA17230; Mon, 11 Dec 2000 01:30:27 -0500 (EST) Message-Id: <4.3.1.2.20001210191146.00b35530@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 10 Dec 2000 19:18:14 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: -16 rev of DHCPv6 spec In-Reply-To: <20001208215916.A20355@itea.ntnu.no> References: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id eBB6Uq914648 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id eBB6V4929261 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22830 At 09:59 PM 12/8/00 +0100, Stig Venås wrote: >I've finally read the draft and have some comments as well. > >On Tue, Nov 28, 2000 at 10:36:09AM -0500, Bernie Volz wrote: > > > In general, this looks GREAT! Excellent job! > >Yes Thanks... > > - Section 22.2's diagram has a "pref. len". Yet this field is not defined > > anywhere in the list of fields. > >I think it must be prefix len, but I agree, the abbreviation is no good. The "prefix length" field was left out of the list of fields (editor's oversight). I will label the field "prefix length" and add a description of the field to the list of fields. > > - In section 10.3.3, there are several mentions of "advertising > availability > > of IP address" ... how is this done (perhaps there will or is an option > that > > will provide this information?). Also, if this capability DOES exist, isn't > > Ted's Discussion point in section 10.5.2 null and void? > >My thought too. I think such an option is a good idea, but it requires >an option not specified in the draft as I understand it. Sorry about the confusion. We have confirmed (in the 12/5 meeting) that carrying addresses in the Advertise is the right thing to do. The details are TBD. I *imagine* the right thing to do is for the client to pass the IAs it needs configurations for in the Solicit. The server can then fill in the IAs and return them to the client in the Advertise. >One more thing. > >It says several places that an IA is identified by (prefix, UUID), why >isn't the UUID enough? We also had this conversation during the 12/5 teleconference and will bring the discussion to the WG on Tuesday, 12/12. - Ralph From owner-dhcp-v4@bucknell.edu Mon Dec 11 02:10:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15007 for ; Mon, 11 Dec 2000 02:10:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBB75f919261; Mon, 11 Dec 2000 02:05:41 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBB75Z920572 for ; Mon, 11 Dec 2000 02:05:35 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.108.155]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id eBB73aL05435; Sun, 10 Dec 2000 23:03:36 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id eBB73du00507; Mon, 11 Dec 2000 00:03:43 -0700 (MST) Message-Id: <200012110703.eBB73du00507@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Comments on draft-ietf-dhc-csr-03.txt In-Reply-To: Message from Stuart Cheshire of "Wed, 29 Nov 2000 16:48:47 PST." <200011300048.QAA22037@scv3.apple.com> Date: Mon, 11 Dec 2000 00:03:39 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've fixed the CSR draft to address the points you have raised, except: > > If the Classless Static Routes option is provided, DHCP clients > > that support this option MUST ignore all Static Routes options > > (option code 33) and Router options (option code 3), if any, > > appearing in the packet. > > > > DHCP clients that support this option and that send a DHCP > > Parameter Request List option MUST request this option and > > MUST NOT request the Router option or the Static Routes option. > > A DHCP server administrator who has to support both old and new clients > can then simply use the Router and Static Routes options to configure the > old clients, and the CSR option to configure the new clients, and there's > no confusing overlap between the two. The problem with this is that clients that do this will not *get* a Routers option even if that is the only information available. Part of the goal here is to have the client work even on networks where the DHCP server is not configured to provide the new option, and in that case a client implemented as described here would not get a default route. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. Obsoletes: draft-ietf-dhc-csr-03.txt December, 2000 Expires May, 2001 The Classless Static Route Option for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Abstract This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. Introduction The IP protocol [4] uses routers to transmit packets from hosts connected to one IP subnet to hosts connected to a different IP subnet. When an IP host (the source host) wishes to transmit a packet to another IP host (the destination), it consults its routing table to determine the IP address of the router that should be used to forward the packet to the destination host. The routing table on an IP host can be maintained in a variety of ways - using a routing information protocol such as RIP [5], ICMP router discovery [6,7] or using the DHCP Router option, defined in [2]. In a network that already provides DHCP service, using DHCP to update the routing table on a DHCP client has several virtues. It is efficient, since it makes use of messages that would have been sent anyway. It is convenient - the DHCP server configuration is already being maintained, so maintaining routing information, at least on a relatively stable network, requires little extra work. If DHCP service is already in use, no additional infrastructure need be deployed. The DHCP protocol as defined in [1] and the options defined in [2] only provide a mechanism for installing a default route or installing a table of classed routes. Classed routes are routes whose subnet mask is implicit in the subnet number - see section 3.2 of [4] for details on classed routing. Classed routing is no longer in common use, so the DHCP Static Route option is no longer useful. Currently, classless routing, described in [8] and [9], is the most commonly-deployed form of routing on the Internet. In classless routing, IP addresses consist of a network number (the combination of the network number and subnet number described in [8]) and a host number. In classed IP, the network number and host number are derived from the IP address using a bitmask whose value is determined by the first few bits of the IP address. In classless IP, the network number and host number are derived from the IP address using a seperate quantity, the subnet mask. In order to determine the network to which a given route applies, an IP host must know both the network number AND the subnet mask for that network. The Static Routes option (option 33) does not provide a subnet mask for each route - it is assumed that the subnet mask is implicit in whatever network number is specified in each route entry. The Classless Static Routes option does provide a subnet mask for each entry, so that the subnet mask can be other than what would be determined using the algorithm specified in [4] and [8]. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document also uses the following terms: "DHCP client" DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Classless Route Option Format The code for this option is TBD, and its minimum length is 5 bytes. This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination. Code Len Destination 1 Router 1 +-----+---+----+-----+----+----+----+----+----+ | TBD | n | d1 | ... | dN | r1 | r2 | r3 | r4 | +-----+---+----+-----+----+----+----+----+----+ Destination 2 Router 2 +----+-----+----+----+----+----+----+ | d1 | ... | dN | r1 | r2 | r3 | r4 | +----+-----+----+----+----+----+----+ In the above example, two static routes are specified. Destination descriptors describe the IP subnet number and subnet mask of a particular destination using a compact encoding. This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number. The width of the subnet mask describes the number of one bits in the mask, so for example a subnet with a subnet number of 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask width of 24. The non-zero portion of the subnet number is simply all of the octets of the subnet number, with the least significant octets that are zero omitted. For a subnet mask width of between 25 and 32, the subnet number will be four octets. Mask widths of between 17 and 24 indicate a three-octet subnet number; between 9 and 16 indicate a two-octet subnet number, between 1 and 8 indicate a one-octet number. As a special case, the default route may be represented by a zero width, with no following subnet number. Host routes are represented by a mask width of 32, followed by four octets containing the IP address of the host. The following table contains some examples: Subnet number Subnet mask Destination descriptor 0 0 0 10.0.0.0 255.0.0.0 8.10 10.17.0.0 255.255.0.0 16.10.17 10.27.129.0 255.255.255.0 24.10.27.129 10.229.0.128 255.255.255.128 25.10.229.0.128 10.198.122.47 255.255.255.255 32.10.198.122.47 Local Subnet Routes In the case where there is more than one IP subnet connected to the local network, the DHCP server MAY send routes for those subnets that specify an IP destination address of 0.0.0.0. DHCP Client Behavior DHCP clients that do not support this option MUST ignore it if it is received from a DHCP server. DHCP clients that support this option MUST install the routes specified in the option. DHCP clients that support this option MUST NOT install the routes specified in the Static Routes option (option code 33) if both a Static Routes option and the Classless Static Routes option are provided. DHCP clients that support this option and that send a DHCP Parameter Request List option MUST request both this option and the Router option [2] in the DHCP Parameter Request List. DHCP clients that support this option and send a parameter request list MUST NOT request the Static Routes option. If the DHCP server returns a Router option, clients that support the Classless Static Routes option MUST use the default route(s) listed in the Router option in addition to the routes listed in the Classless Static Routes option, except as described in the following paragraph. Some TCP/IP stacks can be configured to send ARP request messages on an interface for IP addresses that are on subnets not configured for that interface. Consequently, DHCP clients that implement the Classless Static Routes option MUST check each route to see if the IP destination is 0.0.0.0, and MUST EITHER configure their IP stack to ARP for IP addresses whose routing destination is 0.0.0.0, OR ignore routes with a destination of 0.0.0.0. DHCP clients that support ARPing as described here MUST ignore the Router option (option code 3) if the Router option contains the client's own IP address or an IP address of 0.0.0.0. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to determine if are any bits in the destination network number whose value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination of 129.210.377.4 and a subnet mask of 255.255.255.128. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain some legitimate Classless Static Route options. Because of this, clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to the MTU of the interface that the client is configuring. DHCP Server administrator responsibilities Many clients may not implement the Classless Static Routes option. DHCP server administrators should therefore configure their DHCP servers to send both a Routers option and a Classless Static Routes option, and should specify all default routes in the Routers option, and not specify any default routes in the Classless Static Routes option. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [5] Hedrick, C.L., "Routing Information Protocol", RFC 1058, Rutgers University, June 1, 1988. [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [7] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [8] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. [9] Pummill, T., Manning, B., "Variable Length Subnet Table For IPv4", RFC1878, Alantec, USC/Information Sciences Institute, December, 1995 Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: Ted.Lemon@nominum.com Expiration This document will expire on May 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Mon Dec 11 04:19:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24945 for ; Mon, 11 Dec 2000 04:19:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBB9FA929139; Mon, 11 Dec 2000 04:15:10 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBB9Er922702 for ; Mon, 11 Dec 2000 04:14:53 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id BAA13017 for ; Mon, 11 Dec 2000 01:14:52 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 11 Dec 2000 01:14:52 -0800 Received: from [10.10.2.59] (vpn-gh-1144.apple.com [17.254.140.119]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id BAA29505; Mon, 11 Dec 2000 01:14:47 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 11 Dec 2000 01:14:47 -0800 Subject: Re: Comments on draft-ietf-dhc-csr-03.txt From: Stuart Cheshire To: DHCPv4 discussion list Message-ID: In-Reply-To: <200012110703.eBB73du00507@grosse.bisbee.fugue.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit on 12/10/00 11:03 PM, Ted Lemon wrote: > The problem with this is that clients that do this will not *get* a > Routers option even if that is the only information available. Part > of the goal here is to have the client work even on networks where the > DHCP server is not configured to provide the new option, and in that > case a client implemented as described here would not get a default > route. Good point. What about this option: the client requests both, but only uses the Routers option if no CSR is offered instead? I think we agree that the client should request both. What we're trying to clarify is what to do if the client receives both in the reply: Always use the Routers option, never use the Routers option, or sometimes use the Routers option? If the answer is "sometimes", we should nail down explicitly what those times are. Stuart Cheshire From owner-dhcp-v4@bucknell.edu Mon Dec 11 12:48:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09169 for ; Mon, 11 Dec 2000 12:48:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBBHgP927658; Mon, 11 Dec 2000 12:42:25 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBBHgH925231 for ; Mon, 11 Dec 2000 12:42:17 -0500 (EST) Received: from grosse.bisbee.fugue.com ([207.137.72.115]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id eBBHeEL06689; Mon, 11 Dec 2000 09:40:14 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id eBBHg2e00521; Mon, 11 Dec 2000 10:42:02 -0700 (MST) Message-Id: <200012111742.eBBHg2e00521@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Comments on draft-ietf-dhc-csr-03.txt In-Reply-To: Message from Stuart Cheshire of "Mon, 11 Dec 2000 01:14:47 PST." Date: Mon, 11 Dec 2000 10:42:02 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Right, I just went back over the earlier discussion, and Bernie suggested the same thing you did. I objected because I apparently hadn't understood what Bernie suggested (sorry, Bernie!). What you are proposing, and what Bernie proposed, should work, and makes the draft less complicated, so I have made the changes you both requested. I've enclosed a further revision of the draft below. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. Obsoletes: draft-ietf-dhc-csr-03.txt December, 2000 Expires May, 2001 The Classless Static Route Option for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Abstract This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. Introduction The IP protocol [4] uses routers to transmit packets from hosts connected to one IP subnet to hosts connected to a different IP subnet. When an IP host (the source host) wishes to transmit a packet to another IP host (the destination), it consults its routing table to determine the IP address of the router that should be used to forward the packet to the destination host. The routing table on an IP host can be maintained in a variety of ways - using a routing information protocol such as RIP [5], ICMP router discovery [6,7] or using the DHCP Router option, defined in [2]. In a network that already provides DHCP service, using DHCP to update the routing table on a DHCP client has several virtues. It is efficient, since it makes use of messages that would have been sent anyway. It is convenient - the DHCP server configuration is already being maintained, so maintaining routing information, at least on a relatively stable network, requires little extra work. If DHCP service is already in use, no additional infrastructure need be deployed. The DHCP protocol as defined in [1] and the options defined in [2] only provide a mechanism for installing a default route or installing a table of classed routes. Classed routes are routes whose subnet mask is implicit in the subnet number - see section 3.2 of [4] for details on classed routing. Classed routing is no longer in common use, so the DHCP Static Route option is no longer useful. Currently, classless routing, described in [8] and [9], is the most commonly-deployed form of routing on the Internet. In classless routing, IP addresses consist of a network number (the combination of the network number and subnet number described in [8]) and a host number. In classed IP, the network number and host number are derived from the IP address using a bitmask whose value is determined by the first few bits of the IP address. In classless IP, the network number and host number are derived from the IP address using a seperate quantity, the subnet mask. In order to determine the network to which a given route applies, an IP host must know both the network number AND the subnet mask for that network. The Static Routes option (option 33) does not provide a subnet mask for each route - it is assumed that the subnet mask is implicit in whatever network number is specified in each route entry. The Classless Static Routes option does provide a subnet mask for each entry, so that the subnet mask can be other than what would be determined using the algorithm specified in [4] and [8]. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document also uses the following terms: "DHCP client" DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Classless Route Option Format The code for this option is TBD, and its minimum length is 5 bytes. This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination. Code Len Destination 1 Router 1 +-----+---+----+-----+----+----+----+----+----+ | TBD | n | d1 | ... | dN | r1 | r2 | r3 | r4 | +-----+---+----+-----+----+----+----+----+----+ Destination 2 Router 2 +----+-----+----+----+----+----+----+ | d1 | ... | dN | r1 | r2 | r3 | r4 | +----+-----+----+----+----+----+----+ In the above example, two static routes are specified. Destination descriptors describe the IP subnet number and subnet mask of a particular destination using a compact encoding. This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number. The width of the subnet mask describes the number of one bits in the mask, so for example a subnet with a subnet number of 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask width of 24. The non-zero portion of the subnet number is simply all of the octets of the subnet number, with the least significant octets that are zero omitted. For a subnet mask width of between 25 and 32, the subnet number will be four octets. Mask widths of between 17 and 24 indicate a three-octet subnet number; between 9 and 16 indicate a two-octet subnet number, between 1 and 8 indicate a one-octet number. As a special case, the default route may be represented by a zero width, with no following subnet number. Host routes are represented by a mask width of 32, followed by four octets containing the IP address of the host. The following table contains some examples: Subnet number Subnet mask Destination descriptor 0 0 0 10.0.0.0 255.0.0.0 8.10 10.17.0.0 255.255.0.0 16.10.17 10.27.129.0 255.255.255.0 24.10.27.129 10.229.0.128 255.255.255.128 25.10.229.0.128 10.198.122.47 255.255.255.255 32.10.198.122.47 Local Subnet Routes In the case where there is more than one IP subnet connected to the local network, the DHCP server MAY send routes for those subnets specifying an IP destination address of 0.0.0.0. This statement applies strictly to the Classless Static Routes option. The behaviour of the DHCP client in the case that a Routers option contains a destination of 0.0.0.0 is not specified here. DHCP Client Behavior DHCP clients that do not support this option MUST ignore it if it is received from a DHCP server. DHCP clients that support this option MUST install the routes specified in the option. DHCP clients that support this option MUST NOT install the routes specified in the Static Routes option (option code 33) if both a Static Routes option and the Classless Static Routes option are provided. DHCP clients that support this option and that send a DHCP Parameter Request List option MUST request both this option and the Router option [2] in the DHCP Parameter Request List. DHCP clients that support this option and send a parameter request list MUST NOT request the Static Routes option. The Classless Static Routes option code SHOULD appear in the parameter request list prior to the Routers option code. If the DHCP server returns both a Router option and a Classless Static Routes option, the DHCP client MUST ignore the Routers option. Some TCP/IP stacks can be configured to send ARP request messages on an interface for IP addresses that are on subnets not configured for that interface. Consequently, DHCP clients that implement the Classless Static Routes option MUST check each route to see if the IP destination is 0.0.0.0, and MUST EITHER configure their IP stack to ARP for IP addresses whose routing destination is 0.0.0.0, OR ignore routes with a destination of 0.0.0.0. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to determine if are any bits in the destination network number whose value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination of 129.210.377.4 and a subnet mask of 255.255.255.128. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain some legitimate Classless Static Route options. Because of this, clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to the MTU of the interface that the client is configuring. DHCP Server administrator responsibilities Many clients may not implement the Classless Static Routes option. DHCP server administrators should therefore configure their DHCP servers to send both a Routers option and a Classless Static Routes option, and should specify the default router(s) both in the Routers option and in the Classless Static Routes option. DHCP Server Considerations When a DHCP client requests both the Routers option and the Classless Static Routes option, and the DHCP server is configured with both a Classless Static Routes option and a Routers option that applies to the client, the DHCP server MAY exclude the Routers option from its response. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [5] Hedrick, C.L., "Routing Information Protocol", RFC 1058, Rutgers University, June 1, 1988. [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [7] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [8] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. [9] Pummill, T., Manning, B., "Variable Length Subnet Table For IPv4", RFC1878, Alantec, USC/Information Sciences Institute, December, 1995 Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: Ted.Lemon@nominum.com Expiration This document will expire on May 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Mon Dec 11 16:04:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10123 for ; Mon, 11 Dec 2000 16:04:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBBKxp931760; Mon, 11 Dec 2000 15:59:51 -0500 (EST) Received: from mailserver2.hrz.tu-darmstadt.de (root@mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBBKxf930850 for ; Mon, 11 Dec 2000 15:59:41 -0500 (EST) Received: from hrzpub.tu-darmstadt.de (C3321.karlshof.wh.tu-darmstadt.de [130.83.218.69]) by mailserver2.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id VAA25641 for ; Mon, 11 Dec 2000 21:59:10 +0100 (MET) Received: (from arning@localhost) by hrzpub.tu-darmstadt.de (8.11.0/8.11.0) id eBBKx1001348 for dhcp-v4@bucknell.edu; Mon, 11 Dec 2000 21:59:01 +0100 Date: Mon, 11 Dec 2000 21:59:01 +0100 From: Arni Ingimundarson To: DHCPv4 discussion list Subject: The "pop-server" and "smtp-server" options Message-ID: <20001211215901.A1345@hrzpub.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Reply-To: arning@hrzpub.tu-darmstadt.de Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello. I apologize if I am posting to the wrong forum. How can I make use of these options? Are there any e-mail programs that speak DHCP or does the OS have to support these options and pass them on to the e-mail clients? Regards, Arni From owner-dhcp-v4@bucknell.edu Wed Dec 13 13:25:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25514 for ; Wed, 13 Dec 2000 13:25:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBDIIG924167; Wed, 13 Dec 2000 13:18:16 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBDII1927804 for ; Wed, 13 Dec 2000 13:18:01 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA27470 for ; Wed, 13 Dec 2000 10:17:59 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 13 Dec 2000 10:17:59 -0800 Received: from [207.137.74.247] (vpn-gh-607.apple.com [17.254.138.94]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA01775; Wed, 13 Dec 2000 10:17:58 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Dec 2000 10:18:02 -0800 Subject: Re: The "pop-server" and "smtp-server" options From: Stuart Cheshire To: DHCPv4 discussion list Message-ID: In-Reply-To: <20001211215901.A1345@hrzpub.tu-darmstadt.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit on 12/11/00 12:59 PM, Arni Ingimundarson wrote: > Are there any e-mail programs that speak DHCP or does the OS have to support > these options and pass them on to the e-mail clients? Mac OS 9.1 (out soon) requests the SMTP Server option from the DHCP server, so that a mail client application can use the call below to read the value of the SMTP Server option (option code 69): OTInetGetDHCPConfigInfo(buffer, size, kDefaultInetInterface, 69); Mac OS does not request the POP Server option. We felt that the SMTP relay is dynamic information that may change from network to network, but your POP mailbox is not. The reasoning for this is that if a mobile user visits another network but still tries to send mail via their regular "home" SMTP relay, it will most likely reject mail coming from an "unknown" source address as potential spam. Thus the SMTP relay you should use may change depending on which network you're attached to (and which source IP address you're sending from), and consequently it makes sense to get this information from the DHCP server on each network. In contrast, the POP server where your mailbox is stored remains the same no matter where you connect to the Internet. Just because you're at the IETF meeting doesn't mean that your mail is now all stored on the IETF POP server. Your mail is still stored where it has always been stored -- on your regular POP server -- and your mail client needs to continue to get it from that server. Stuart Cheshire From owner-dhcp-v4@bucknell.edu Wed Dec 13 23:41:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00100 for ; Wed, 13 Dec 2000 23:41:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBE4Z8927040; Wed, 13 Dec 2000 23:35:08 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBE4Yp921718 for ; Wed, 13 Dec 2000 23:34:51 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA02205 for ; Wed, 13 Dec 2000 20:34:50 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 13 Dec 2000 20:34:49 -0800 Received: from [207.137.73.49] (vpn-gh-1080.apple.com [17.254.140.55]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id UAA08841; Wed, 13 Dec 2000 20:34:49 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Dec 2000 20:34:52 -0800 Subject: Re: The "pop-server" and "smtp-server" options From: Stuart Cheshire To: DHCPv4 discussion list CC: DHCPv4 discussion list Message-ID: In-Reply-To: <20001213134120.B22744@isc.upenn.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit on 12/13/00 10:41 AM, Dikran Kassabian wrote: > I suppose, unless the SMTP server administrators and the client use SMTP > Authentication (rfc2554). I think I'd much rather see more of that than > more accommodation via DHCP. Sorry, I had some assumptions that I didn't state: Obviously, it is better to have secure authentication, but *if* you don't have secure authentication and you're filtering by source IP address instead, then that means that the SMTP relay you use has to depend on your source address. > Unless the folks running the DHCP servers and administering the IP > address space aren't the same folks as those who support the desktops > for the users or otherwise know which of the many available SMTP > servers is the right one for that user. Locating any service on the network is properly a service discovery problem -- but *if* you're not using a service discovery protocol, then stuffing this information into the DHCP packet instead is a workable interim solution. The point of my email was not to justify supporting the SMTP server option, but to explain why we decided not to support other options (like the POP server option) which seemed to make even less sense. Stuart Cheshire From owner-dhcp-v4@bucknell.edu Thu Dec 14 01:50:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22790 for ; Thu, 14 Dec 2000 01:50:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBE6fL900019; Thu, 14 Dec 2000 01:41:21 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBE6f5907460 for ; Thu, 14 Dec 2000 01:41:06 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.110.144]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id eBE6d1L12777; Wed, 13 Dec 2000 22:39:01 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id eBE6XM000710; Wed, 13 Dec 2000 23:33:23 -0700 (MST) Message-Id: <200012140633.eBE6XM000710@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: The "pop-server" and "smtp-server" options In-Reply-To: Message from Stuart Cheshire of "Wed, 13 Dec 2000 20:34:52 PST." Date: Wed, 13 Dec 2000 23:33:22 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Locating any service on the network is properly a service discovery problem > -- but *if* you're not using a service discovery protocol, then stuffing > this information into the DHCP packet instead is a workable interim > solution. I'd be pretty upset if my MUA started dropping my email on the wrong SMTP server. Seriously, can you think of a real world situation with a real user where this would actually work? I don't mean to pummel you about it - it just seems to me like there isn't such a thing - there's a reason why people have to type in the IP address of their SMTP server. > The point of my email was not to justify supporting the SMTP server option, > but to explain why we decided not to support other options (like the POP > server option) which seemed to make even less sense. I know - it's just that I really would like to see the apple MUAs be more configurable, but not in this way. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Dec 19 22:32:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03023; Tue, 19 Dec 2000 22:32:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBK3Sa929582; Tue, 19 Dec 2000 22:28:37 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBK3SL928710 for ; Tue, 19 Dec 2000 22:28:21 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Dec 2000 18:26:00 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 18:26:43 -0800 (Pacific Standard Time) Received: from DF-SCOOBY.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 19 Dec 2000 18:26:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Progress on the DHCPv6 draft in SanDiego IETF meeting Date: Tue, 19 Dec 2000 18:26:40 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A6819C53B@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Progress on the DHCPv6 draft in SanDiego IETF meeting Thread-Index: AcBqLEi2sUObiKrdSxqLVQb/35+f2A== From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 20 Dec 2000 02:26:42.0782 (UTC) FILETIME=[4A86AFE0:01C06A2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id eBK3SM911681 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi all, In the conference call a week prior to the IETF meeting, we managed to hash out several outstanding issues with the latest version of the DHCP draft. There were some issues that needed further discussion and clarification such as IA. I was wondering what progress was made in the San Diego IETF. Can some one share in this forum what was achieved in the SanDiego IETF and what else needs to be discussed further for the draft to move forward? thx, Thiru From owner-dhcp-v4@bucknell.edu Wed Dec 20 13:38:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09471 for ; Wed, 20 Dec 2000 13:38:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBKIW0928568; Wed, 20 Dec 2000 13:32:00 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBKIVu900355 for ; Wed, 20 Dec 2000 13:31:56 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id eBKIThL27895 for ; Wed, 20 Dec 2000 10:29:44 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id eBKITwv00965 for ; Wed, 20 Dec 2000 11:29:58 -0700 (MST) Message-Id: <200012201829.eBKITwv00965@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: Any last comments on CSR? Date: Wed, 20 Dec 2000 11:29:58 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN If not, I'm going to submit this roughly as is. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. Obsoletes: draft-ietf-dhc-csr-03.txt December, 2000 Expires May, 2001 The Classless Static Route Option for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Abstract This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. Introduction The IP protocol [4] uses routers to transmit packets from hosts connected to one IP subnet to hosts connected to a different IP subnet. When an IP host (the source host) wishes to transmit a packet to another IP host (the destination), it consults its routing table to determine the IP address of the router that should be used to forward the packet to the destination host. The routing table on an IP host can be maintained in a variety of ways - using a routing information protocol such as RIP [5], ICMP router discovery [6,7] or using the DHCP Router option, defined in [2]. In a network that already provides DHCP service, using DHCP to update the routing table on a DHCP client has several virtues. It is efficient, since it makes use of messages that would have been sent anyway. It is convenient - the DHCP server configuration is already being maintained, so maintaining routing information, at least on a relatively stable network, requires little extra work. If DHCP service is already in use, no additional infrastructure need be deployed. The DHCP protocol as defined in [1] and the options defined in [2] only provide a mechanism for installing a default route or installing a table of classed routes. Classed routes are routes whose subnet mask is implicit in the subnet number - see section 3.2 of [4] for details on classed routing. Classed routing is no longer in common use, so the DHCP Static Route option is no longer useful. Currently, classless routing, described in [8] and [9], is the most commonly-deployed form of routing on the Internet. In classless routing, IP addresses consist of a network number (the combination of the network number and subnet number described in [8]) and a host number. In classed IP, the network number and host number are derived from the IP address using a bitmask whose value is determined by the first few bits of the IP address. In classless IP, the network number and host number are derived from the IP address using a seperate quantity, the subnet mask. In order to determine the network to which a given route applies, an IP host must know both the network number AND the subnet mask for that network. The Static Routes option (option 33) does not provide a subnet mask for each route - it is assumed that the subnet mask is implicit in whatever network number is specified in each route entry. The Classless Static Routes option does provide a subnet mask for each entry, so that the subnet mask can be other than what would be determined using the algorithm specified in [4] and [8]. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document also uses the following terms: "DHCP client" DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Classless Route Option Format The code for this option is TBD, and its minimum length is 5 bytes. This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination. Code Len Destination 1 Router 1 +-----+---+----+-----+----+----+----+----+----+ | TBD | n | d1 | ... | dN | r1 | r2 | r3 | r4 | +-----+---+----+-----+----+----+----+----+----+ Destination 2 Router 2 +----+-----+----+----+----+----+----+ | d1 | ... | dN | r1 | r2 | r3 | r4 | +----+-----+----+----+----+----+----+ In the above example, two static routes are specified. Destination descriptors describe the IP subnet number and subnet mask of a particular destination using a compact encoding. This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number. The width of the subnet mask describes the number of one bits in the mask, so for example a subnet with a subnet number of 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask width of 24. The non-zero portion of the subnet number is simply all of the octets of the subnet number, with the least significant octets that are zero omitted. For a subnet mask width of between 25 and 32, the subnet number will be four octets. Mask widths of between 17 and 24 indicate a three-octet subnet number; between 9 and 16 indicate a two-octet subnet number, between 1 and 8 indicate a one-octet number. As a special case, the default route may be represented by a zero width, with no following subnet number. Host routes are represented by a mask width of 32, followed by four octets containing the IP address of the host. The following table contains some examples: Subnet number Subnet mask Destination descriptor 0 0 0 10.0.0.0 255.0.0.0 8.10 10.17.0.0 255.255.0.0 16.10.17 10.27.129.0 255.255.255.0 24.10.27.129 10.229.0.128 255.255.255.128 25.10.229.0.128 10.198.122.47 255.255.255.255 32.10.198.122.47 Local Subnet Routes In the case where there is more than one IP subnet connected to the local network, the DHCP server MAY send routes for those subnets specifying an IP destination address of 0.0.0.0. This statement applies strictly to the Classless Static Routes option. The behaviour of the DHCP client in the case that a Routers option contains a destination of 0.0.0.0 is not specified here. DHCP Client Behavior DHCP clients that do not support this option MUST ignore it if it is received from a DHCP server. DHCP clients that support this option MUST install the routes specified in the option. DHCP clients that support this option MUST NOT install the routes specified in the Static Routes option (option code 33) if both a Static Routes option and the Classless Static Routes option are provided. DHCP clients that support this option and that send a DHCP Parameter Request List option MUST request both this option and the Router option [2] in the DHCP Parameter Request List. DHCP clients that support this option and send a parameter request list MUST NOT request the Static Routes option. The Classless Static Routes option code SHOULD appear in the parameter request list prior to the Routers option code. If the DHCP server returns both a Router option and a Classless Static Routes option, the DHCP client MUST ignore the Routers option. Some TCP/IP stacks can be configured to send ARP request messages on an interface for IP addresses that are on subnets not configured for that interface. Consequently, DHCP clients that implement the Classless Static Routes option MUST check each route to see if the IP destination is 0.0.0.0, and MUST EITHER configure their IP stack to ARP for IP addresses whose routing destination is 0.0.0.0, OR ignore routes found in the Classless Static Routes option that have a destination of 0.0.0.0. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to determine if there are any bits in the destination network number whose value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination of 129.210.377.4 and a subnet mask of 255.255.255.128. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain some legitimate Classless Static Route options. Because of this, clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to the MTU of the interface that the client is configuring. DHCP Server administrator responsibilities Many clients may not implement the Classless Static Routes option. DHCP server administrators should therefore configure their DHCP servers to send both a Routers option and a Classless Static Routes option, and should specify the default router(s) both in the Routers option and in the Classless Static Routes option. DHCP Server Considerations When a DHCP client requests both the Routers option and the Classless Static Routes option, and the DHCP server is configured with both a Classless Static Routes option and a Routers option that applies to the client, the DHCP server MAY exclude the Routers option from its response. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [5] Hedrick, C.L., "Routing Information Protocol", RFC 1058, Rutgers University, June 1, 1988. [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [7] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [8] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. [9] Pummill, T., Manning, B., "Variable Length Subnet Table For IPv4", RFC1878, Alantec, USC/Information Sciences Institute, December, 1995 Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: Ted.Lemon@nominum.com Expiration This document will expire on May 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Wed Dec 20 15:26:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13661 for ; Wed, 20 Dec 2000 15:26:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBKKJM932091; Wed, 20 Dec 2000 15:19:23 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBKKJB917699 for ; Wed, 20 Dec 2000 15:19:11 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 15:18:55 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8603607552@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Any last comments on CSR? Date: Wed, 20 Dec 2000 15:18:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: Weren't you going to add something into this draft about multiple options and how to concatentate them? Perhaps something like: If the routing table is too large to fit into a single option (which is restricted to a length of 255 bytes), multiple options may be used. The client must concatentate the these multipe options in the same order as they appear in the message (the first option's data is start of the routing table and the last option's data is the end of the routing table). Perhaps appropriate text needs appear in the client considerations and also server considerations sections. - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, December 20, 2000 1:30 PM To: DHCPv4 discussion list Subject: Any last comments on CSR? If not, I'm going to submit this roughly as is. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. Obsoletes: draft-ietf-dhc-csr-03.txt December, 2000 Expires May, 2001 The Classless Static Route Option for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Abstract This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. Introduction The IP protocol [4] uses routers to transmit packets from hosts connected to one IP subnet to hosts connected to a different IP subnet. When an IP host (the source host) wishes to transmit a packet to another IP host (the destination), it consults its routing table to determine the IP address of the router that should be used to forward the packet to the destination host. The routing table on an IP host can be maintained in a variety of ways - using a routing information protocol such as RIP [5], ICMP router discovery [6,7] or using the DHCP Router option, defined in [2]. In a network that already provides DHCP service, using DHCP to update the routing table on a DHCP client has several virtues. It is efficient, since it makes use of messages that would have been sent anyway. It is convenient - the DHCP server configuration is already being maintained, so maintaining routing information, at least on a relatively stable network, requires little extra work. If DHCP service is already in use, no additional infrastructure need be deployed. The DHCP protocol as defined in [1] and the options defined in [2] only provide a mechanism for installing a default route or installing a table of classed routes. Classed routes are routes whose subnet mask is implicit in the subnet number - see section 3.2 of [4] for details on classed routing. Classed routing is no longer in common use, so the DHCP Static Route option is no longer useful. Currently, classless routing, described in [8] and [9], is the most commonly-deployed form of routing on the Internet. In classless routing, IP addresses consist of a network number (the combination of the network number and subnet number described in [8]) and a host number. In classed IP, the network number and host number are derived from the IP address using a bitmask whose value is determined by the first few bits of the IP address. In classless IP, the network number and host number are derived from the IP address using a seperate quantity, the subnet mask. In order to determine the network to which a given route applies, an IP host must know both the network number AND the subnet mask for that network. The Static Routes option (option 33) does not provide a subnet mask for each route - it is assumed that the subnet mask is implicit in whatever network number is specified in each route entry. The Classless Static Routes option does provide a subnet mask for each entry, so that the subnet mask can be other than what would be determined using the algorithm specified in [4] and [8]. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document also uses the following terms: "DHCP client" DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Classless Route Option Format The code for this option is TBD, and its minimum length is 5 bytes. This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination. Code Len Destination 1 Router 1 +-----+---+----+-----+----+----+----+----+----+ | TBD | n | d1 | ... | dN | r1 | r2 | r3 | r4 | +-----+---+----+-----+----+----+----+----+----+ Destination 2 Router 2 +----+-----+----+----+----+----+----+ | d1 | ... | dN | r1 | r2 | r3 | r4 | +----+-----+----+----+----+----+----+ In the above example, two static routes are specified. Destination descriptors describe the IP subnet number and subnet mask of a particular destination using a compact encoding. This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number. The width of the subnet mask describes the number of one bits in the mask, so for example a subnet with a subnet number of 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask width of 24. The non-zero portion of the subnet number is simply all of the octets of the subnet number, with the least significant octets that are zero omitted. For a subnet mask width of between 25 and 32, the subnet number will be four octets. Mask widths of between 17 and 24 indicate a three-octet subnet number; between 9 and 16 indicate a two-octet subnet number, between 1 and 8 indicate a one-octet number. As a special case, the default route may be represented by a zero width, with no following subnet number. Host routes are represented by a mask width of 32, followed by four octets containing the IP address of the host. The following table contains some examples: Subnet number Subnet mask Destination descriptor 0 0 0 10.0.0.0 255.0.0.0 8.10 10.17.0.0 255.255.0.0 16.10.17 10.27.129.0 255.255.255.0 24.10.27.129 10.229.0.128 255.255.255.128 25.10.229.0.128 10.198.122.47 255.255.255.255 32.10.198.122.47 Local Subnet Routes In the case where there is more than one IP subnet connected to the local network, the DHCP server MAY send routes for those subnets specifying an IP destination address of 0.0.0.0. This statement applies strictly to the Classless Static Routes option. The behaviour of the DHCP client in the case that a Routers option contains a destination of 0.0.0.0 is not specified here. DHCP Client Behavior DHCP clients that do not support this option MUST ignore it if it is received from a DHCP server. DHCP clients that support this option MUST install the routes specified in the option. DHCP clients that support this option MUST NOT install the routes specified in the Static Routes option (option code 33) if both a Static Routes option and the Classless Static Routes option are provided. DHCP clients that support this option and that send a DHCP Parameter Request List option MUST request both this option and the Router option [2] in the DHCP Parameter Request List. DHCP clients that support this option and send a parameter request list MUST NOT request the Static Routes option. The Classless Static Routes option code SHOULD appear in the parameter request list prior to the Routers option code. If the DHCP server returns both a Router option and a Classless Static Routes option, the DHCP client MUST ignore the Routers option. Some TCP/IP stacks can be configured to send ARP request messages on an interface for IP addresses that are on subnets not configured for that interface. Consequently, DHCP clients that implement the Classless Static Routes option MUST check each route to see if the IP destination is 0.0.0.0, and MUST EITHER configure their IP stack to ARP for IP addresses whose routing destination is 0.0.0.0, OR ignore routes found in the Classless Static Routes option that have a destination of 0.0.0.0. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to determine if there are any bits in the destination network number whose value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination of 129.210.377.4 and a subnet mask of 255.255.255.128. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain some legitimate Classless Static Route options. Because of this, clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to the MTU of the interface that the client is configuring. DHCP Server administrator responsibilities Many clients may not implement the Classless Static Routes option. DHCP server administrators should therefore configure their DHCP servers to send both a Routers option and a Classless Static Routes option, and should specify the default router(s) both in the Routers option and in the Classless Static Routes option. DHCP Server Considerations When a DHCP client requests both the Routers option and the Classless Static Routes option, and the DHCP server is configured with both a Classless Static Routes option and a Routers option that applies to the client, the DHCP server MAY exclude the Routers option from its response. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [5] Hedrick, C.L., "Routing Information Protocol", RFC 1058, Rutgers University, June 1, 1988. [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [7] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [8] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. [9] Pummill, T., Manning, B., "Variable Length Subnet Table For IPv4", RFC1878, Alantec, USC/Information Sciences Institute, December, 1995 Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: Ted.Lemon@nominum.com Expiration This document will expire on May 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Wed Dec 20 16:10:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15152 for ; Wed, 20 Dec 2000 16:10:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBKL4t901443; Wed, 20 Dec 2000 16:04:55 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBKL4f914589 for ; Wed, 20 Dec 2000 16:04:41 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id eBKL2PL28173; Wed, 20 Dec 2000 13:02:25 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id eBKL0cv01464; Wed, 20 Dec 2000 14:00:38 -0700 (MST) Message-Id: <200012202100.eBKL0cv01464@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Any last comments on CSR? In-Reply-To: Message from Bernie Volz of "Wed, 20 Dec 2000 15:18:54 EST." <63D30D6E10CFD11190A90000F805FE8603607552@lespaul.process.com> Date: Wed, 20 Dec 2000 14:00:38 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Weren't you going to add something into this draft about multiple options > and how to concatentate them? Oh, right. I forgot to mention that - thanks for reminding me. I'm actually going to reference a second draft with which I am almost done, so I guess I'll send that one out first. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Dec 21 11:31:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23516 for ; Thu, 21 Dec 2000 11:31:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBLGP8918873; Thu, 21 Dec 2000 11:25:08 -0500 (EST) Received: from basmail.basystems.com (basmail.basystems.com [209.211.220.7]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBLGP6905871 for ; Thu, 21 Dec 2000 11:25:06 -0500 (EST) Received: from jsmall ([146.71.193.194]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 310; Thu, 21 Dec 2000 11:27:04 -0500 From: "Jeff Small" To: DHCPv4 discussion list Cc: "Jeff Small" Subject: DHCP MIB Date: Thu, 21 Dec 2000 11:27:06 -0600 Message-ID: <001901c06b73$3d743190$c2c14792@basystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Reply-To: jsmall@basystems.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit During my review of the DHCP MIB draft dated 11/13/2000 http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-05.txt I noticed several inconsistencies in the new serverSubnetFreeAddressLowThreshold and serverSubnetFreeAddressHighThreshold object descriptions. Is there a later revision of the MIB available that has corrections in this area? Thank you. Jeff Small Senior Software Engineer ADC Telecommunications (formerly Broadband Access Systems) jsmall@basystems.com From owner-dhcp-v6@bucknell.edu Thu Dec 28 08:07:40 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15636; Thu, 28 Dec 2000 08:07:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBSD3c912097; Thu, 28 Dec 2000 08:03:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBSD3P912255; Thu, 28 Dec 2000 08:03:25 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA10173; Thu, 28 Dec 2000 05:03:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBSD39J23192; Thu, 28 Dec 2000 05:03:09 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA16046; Thu, 28 Dec 2000 05:02:44 -0800 (PST) Message-Id: <4.3.1.2.20001228075233.00b93ae0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 28 Dec 2000 08:02:28 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCS: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used and this option should be assigned suboption code 4. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v4@bucknell.edu Thu Dec 28 08:10:23 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15664 for ; Thu, 28 Dec 2000 08:10:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBSD3c905493; Thu, 28 Dec 2000 08:03:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBSD3P912255; Thu, 28 Dec 2000 08:03:25 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA10173; Thu, 28 Dec 2000 05:03:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBSD39J23192; Thu, 28 Dec 2000 05:03:09 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA16046; Thu, 28 Dec 2000 05:02:44 -0800 (PST) Message-Id: <4.3.1.2.20001228075233.00b93ae0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 28 Dec 2000 08:02:28 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCS: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used and this option should be assigned suboption code 4. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v4@bucknell.edu Thu Dec 28 11:27:46 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17017 for ; Thu, 28 Dec 2000 11:27:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBSGMG919373; Thu, 28 Dec 2000 11:22:16 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBSGM8926589 for ; Thu, 28 Dec 2000 11:22:09 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20005 for ; Thu, 28 Dec 2000 08:21:58 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBSGLs616854 for ; Thu, 28 Dec 2000 08:21:54 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18475 for ; Thu, 28 Dec 2000 08:21:52 -0800 (PST) Message-Id: <4.3.1.2.20001228110144.00b894e0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 28 Dec 2000 11:21:58 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Option 115, failover Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Some time ago, option code 115 was allocated for a failover protocol option. With the evolution of the design of the failover protocol, this option is no longer needed. I intend to contact IANA to return 115 to the pool of available option codes. If you think we should *not* recycle 115 - for example, if you know that 115 is actually in use somewhere - let me know by 1/5. Otherwise, I will go ahead and recycle 115. - Ralph From owner-dhcp-v4@bucknell.edu Sun Dec 31 01:37:19 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10598 for ; Sun, 31 Dec 2000 01:37:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eBV6Un912040; Sun, 31 Dec 2000 01:30:49 -0500 (EST) Received: from renater.com (www.smc-europe.com [195.114.67.154]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eBV6Uf901627 for ; Sun, 31 Dec 2000 01:30:41 -0500 (EST) Received: from OLIPC2K [207.38.10.22] by renater.com (SMTPD32-6.00) id A286E8FE0050; Sun, 31 Dec 2000 07:30:30 +0100 Message-ID: <009b01c072f3$b7f7bea0$3201a8c0@OLIPC2K> From: "oli" To: DHCPv4 discussion list Subject: Serving DHCP on several adapters on the same machine Date: Sat, 30 Dec 2000 22:34:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: oli@accton.fr Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello All ! I am trying to understand how to setup the dhcpd.conf in order to provide DHCP on several adapter cards. Here is an example. The linux machine has 4 adapters: eth0 193.51.136.253 mask 255.255.255.252 no DHCP here, it's a 2-hosts subnet with static public IP. eth1 192.168.1.1 mask 255.255.255.0 we want to provide DHCP to hosts in this subnet [192.168.1.100 -> 192.168.1.200] eth2 192.168.2.1 mask 255.255.255.192 we want to provide DHCP to hosts in this subnet [192.168.2.10 -> 192.168.1.20] eth3 192.168.3.1 mask 255.255.255.192 we want to provide DHCP to hosts in this subnet [192.168.3.10 -> 192.168.3.20] How can you configure DHCPd to serve those multiple adapters ? Thank you so very much for your help ! Olivier.