From owner-dhcp-v4@bucknell.edu Wed Mar 1 09:19:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02269 for ; Wed, 1 Mar 2000 09:19:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA17004; Wed, 1 Mar 2000 09:19:10 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA30535; Wed, 1 Mar 2000 09:18:54 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA09706; Wed, 1 Mar 2000 09:18:54 -0500 (EST) Message-Id: <4.2.2.20000301091002.00a62840@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 09:18:51 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG meeting in Adelaide Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN As is our custom, the DHC WG will meet twice at the upcoming IETF meeting in Adelaide - one session for DHCPv4 issues and one for DHCPv6 issues. Tentatively, the DHCPv4 session will occur on Tuesday, 3/28 and the DHCPv6 session on Wednesday, 3/29. If you would like to be included on the agenda for either session, please send me a note describing your agenda item and an estimate of the amount of time you'll neeed. Please get your agenda requests to me by 3/10. Note that the cut-off for I-D submission is also 3/10. The following two items are on the agenda for the DHCPv4 session: Use of DHCP for configuration of IPSEC tunnel mode draft-ietf-ipsec-dhcp-04.txt Bernard Aboba Use of DHCP for configuring multicast DNS behavior draft-aboba-dhc-mdns-conf-00.txt Bernard Aboba - Ralph Droms From owner-dhcp-v6@bucknell.edu Wed Mar 1 09:22:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02359 for ; Wed, 1 Mar 2000 09:22:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA13829; Wed, 1 Mar 2000 09:19:06 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA30535; Wed, 1 Mar 2000 09:18:54 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA09706; Wed, 1 Mar 2000 09:18:54 -0500 (EST) Message-Id: <4.2.2.20000301091002.00a62840@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 09:18:51 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: WG meeting in Adelaide 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 As is our custom, the DHC WG will meet twice at the upcoming IETF meeting in Adelaide - one session for DHCPv4 issues and one for DHCPv6 issues. Tentatively, the DHCPv4 session will occur on Tuesday, 3/28 and the DHCPv6 session on Wednesday, 3/29. If you would like to be included on the agenda for either session, please send me a note describing your agenda item and an estimate of the amount of time you'll neeed. Please get your agenda requests to me by 3/10. Note that the cut-off for I-D submission is also 3/10. The following two items are on the agenda for the DHCPv4 session: Use of DHCP for configuration of IPSEC tunnel mode draft-ietf-ipsec-dhcp-04.txt Bernard Aboba Use of DHCP for configuring multicast DNS behavior draft-aboba-dhc-mdns-conf-00.txt Bernard Aboba - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Mar 1 11:31:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07122 for ; Wed, 1 Mar 2000 11:31:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA00435; Wed, 1 Mar 2000 11:29:48 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA02837 for ; Wed, 1 Mar 2000 11:29:12 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA09821 for ; Wed, 1 Mar 2000 11:29:11 -0500 (EST) Message-Id: <4.2.2.20000301112813.00a94400@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 11:29:00 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHCP options for SIP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The SIP WG has developed a proposal for DHCP options to carry SIP configuration information. The DHC WG reviewed a preliminary version of this document, draft-nair-sip-dhcp-00.txt. The authors have revised the document based on DHC WG input, and would like to submit the new proposal into the standards track. The SIP WG would like to "fast track" this proposal, as it is not complex, the I-D is short and the authors have revised the proposal based on DHC WG input. To move the proposal forward efficiently, the SIP WG has issued a WG last call on the current draft, draft-ietf-sip-dhcp-00.txt. In parallel with the SIP WG last call, I am issuing a DHC WG last call on the draft. Please review the revised document and post your comments to the dhcp-v4@bucknell.edu mailing list. The DHC WG last call will end on March 17. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Mar 1 19:24:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18803 for ; Wed, 1 Mar 2000 19:24:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA20750; Wed, 1 Mar 2000 19:24:09 -0500 (EST) Received: from fs-sd-exch1.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA00431 for ; Wed, 1 Mar 2000 19:23:55 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Mar 2000 16:22:49 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999FDC@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: RE: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Wed, 1 Mar 2000 16:22:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Any comments? ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Eric Michelsen > Sent: Wednesday, February 23, 2000 9:14 > To: 'dhcp-v4@bucknell.edu' > Subject: agent-options-08 > > > Why the prohibition against modifying BOOTP requests (sec > 2.1, par 2)? The clients may be old, and may issue BOOTP > instead of DHCP. Since the Agent-information is for the > benefit of the access device and the DHCP server, why disrupt > existing deployments of BOOTP clients, when the agent and > server don't care? > > As an access equipment vendor, I have several scenarios where > the access equipment has the knowledge of Circuit ID, etc., > but is not acting at a protocol layer that allows it to > actually *be* a DHCP relay agent. These applications require > that upstream Relay Agents accept requests where the > "agent-information" is present, but giaddr = 0. Because > servers and agents "know" if they require circuit IDs or not, > I don't see any security benefit to requiring *relay agents* > to discard such requests (sec 2.1, par 3). A better > statement would be that "devices inserting > 'agent-information' must remove any pre-existing > 'agent-information', to prevent spoofing." > > The intent of sec 2.1, par 6 is not clear to me: why would > the sname or file fields have agent-information options in > them, and why shouldn't the access device remove them? > > The intent of sec 2.1, par 8 is not clear to me: for > security, the access device certainly WILL enforce valid > agent-information, whether this document requires it or not. > But what is the intent here? Along with this, sec 2.2, par > 4, DHCP servers may indeed require the agent-options field to > be present. Anything else may be a potential security weakness. > > Sec 2.1.1, for clarity: why would a relay agent receive a > relayed request? Doesn't the original relay-agent forward > the request by unicast directly to the server? > > Sec 3.2, I think the "remote-ID" should be clarified, for the > case of PVC-like connections to the premise (e.g., DSL), the > remote-ID may be an identifier of the physical line > (essentially, all the circuit-ID suggestions, plus the > additional suggestions given). From the descriptions, it > seems like servers interpret remote-ID as the definitive > client identification, and circuit-ID may be interesting, but > not necessarily definitive. > ------------------------------------------- > Eric L. Michelsen, Copper Mountain Networks > From owner-dhcp-v4@bucknell.edu Thu Mar 2 05:50:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09655 for ; Thu, 2 Mar 2000 05:50:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA32092; Thu, 2 Mar 2000 05:48:48 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA02611 for ; Thu, 2 Mar 2000 05:48:41 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA20684; Thu, 2 Mar 2000 03:48:31 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA25664; Thu, 2 Mar 2000 03:48:31 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id FAA11272; Thu, 2 Mar 2000 05:48:29 -0500 (EST) Message-Id: <200003021048.FAA11272@noah.dma.isg.mot.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list , mpatrick@dma.isg.mot.com Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-reply-to: Your message of "Wed, 01 Mar 2000 16:22:48 EST." <47FEF5D2BE22D311AA8600508B108915999FDC@fs-sd-exch1.coppermountain.com> Date: Thu, 02 Mar 2000 05:48:29 -0500 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Eric, Sorry about the delay in replying. Responses inline. -mike >>>>> "Eric" == Eric Michelsen writes: > Any comments? ------------------------------------------- Eric > L. Michelsen, Copper Mountain Networks >> -----Original Message----- From: Eric Michelsen Sent: Wednesday, >> February 23, 2000 9:14 To: 'dhcp-v4@bucknell.edu' Subject: >> agent-options-08 >> >> >> Why the prohibition against modifying BOOTP requests (sec 2.1, par >> 2)? The clients may be old, and may issue BOOTP instead of DHCP. >> Since the Agent-information is for the benefit of the access device >> and the DHCP server, why disrupt existing deployments of BOOTP >> clients, when the agent and server don't care? The relay agent would have to do a lot more than just add the agent options; it would have to *change* the BOOTP to a DHCP by adding the magic number. It wouldn't know, of course, critical other DHCP-only info like client ID. Changing BOOTP to DHCP is a big can of worms we can discuss separately but not something to add in at the last minute here. >> >> As an access equipment vendor, I have several scenarios where the >> access equipment has the knowledge of Circuit ID, etc., but is not >> acting at a protocol layer that allows it to actually *be* a DHCP >> relay agent. These applications require that upstream Relay Agents >> accept requests where the "agent-information" is present, but >> giaddr = 0. Because servers and agents "know" if they require >> circuit IDs or not, I don't see any security benefit to requiring >> *relay agents* to discard such requests (sec 2.1, par 3). A better >> statement would be that "devices inserting 'agent-information' must >> remove any pre-existing 'agent-information', to prevent spoofing." We've discussed anti-spoofing in the WG, including, for instance, "layering" multiple relay agent options. We've decided to keep the principle that "he that relays adds giaddr". That is, either both are added or neither. Note, btw, that access equipment that are bridges need not be precluded from acting as relay agents, i.e. adding the agent option as well as filling in giaddr. >> >> The intent of sec 2.1, par 6 is not clear to me: why would the >> sname or file fields have agent-information options in them, and >> why shouldn't the access device remove them? Using "option overload" significantly complicated the logic, (and so programming and testing) for adding options. It was felt to be an unnecessary complication, and so it is precluded. >> >> The intent of sec 2.1, par 8 is not clear to me: for security, the >> access device certainly WILL enforce valid agent-information, >> whether this document requires it or not. But what is the intent >> here? Along with this, sec 2.2, par 4, DHCP servers may indeed >> require the agent-options field to be present. Anything else may >> be a potential security weakness. Unicast packets, including DHCP, are often forwarded by the "fast path" hardware/software forwarding engine, and for performance reasons are not required to be modified. It is a matter of bilateral agreement between the relay agent and server as to whether unicast DHCP lease renewals are marked. >> >> Sec 2.1.1, for clarity: why would a relay agent receive a relayed >> request? Doesn't the original relay-agent forward the request by >> unicast directly to the server? There are situations in which one relay agent forwards to another. We added this language to handle such cases. This might be the case, for instance, when multiple subnets with separate servers become served by a single "super DHCP server". Another case where this happens is when a customer premise downstream of cable/DSL modem has a router; this router is the first hop outer and so has to relay the broadcast DHCP-DISCOVER, but it is downstream of the "circuit" and doesn't know the circuit (or remote) ID. >> >> Sec 3.2, I think the "remote-ID" should be clarified, for the case >> of PVC-like connections to the premise (e.g., DSL), the remote-ID >> may be an identifier of the physical line (essentially, all the >> circuit-ID suggestions, plus the additional suggestions given). >> From the descriptions, it seems like servers interpret remote-ID as >> the definitive client identification, and circuit-ID may be >> interesting, but not necessarily definitive. I'm hesitant to add the language "definitive client identification". I can imagine a DSL scenario, say, where the "definitive client identification" is pre-assigned ATM VC IDs in the DSLAM. In this case, the circuit ID is the option to be used by the server, because the remote ATM "caller ID" wouldn't be known from SVC signalling. I already give "ATM virtual circuit number" as one of the choices of the circuit ID. >> ------------------------------------------- Eric L. Michelsen, >> Copper Mountain Networks >> From owner-dhcp-v4@bucknell.edu Thu Mar 2 06:08:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09765 for ; Thu, 2 Mar 2000 06:07:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA19706; Thu, 2 Mar 2000 06:07:52 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA18148 for ; Thu, 2 Mar 2000 06:07:45 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA03719; Thu, 2 Mar 2000 04:07:43 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id EAA27817; Thu, 2 Mar 2000 04:07:43 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id GAA12046; Thu, 2 Mar 2000 06:07:42 -0500 (EST) Message-Id: <200003021107.GAA12046@noah.dma.isg.mot.com> To: DHCPv4 discussion list cc: dhcp-v4@bucknell.edu Subject: draft-dhc-agent-options-09.txt Date: Thu, 02 Mar 2000 06:07:41 -0500 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Drafts editor, Please file the following draft in the DHC working group. DHC Group, here's version -09 with the subnet mask sub-option removed. As we discussed, the subnet mask sub-option was the major technical issue raised during the last call. -mike INTERNET DRAFT DHC Working Grop Michael Patrick Motorola ING March 2, 2000 DHCP Relay Agent Information Option Status of this Memo This document is an Internet Draft and is in full conformance of section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 Shado Directories can be accessed at http://ww.ietf.org/shadow.html 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 [4]. Abstract Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. Expires September 2000 [Page 1] March 2, 2000 The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem. Table of Contents 1 Introduction........................................... 3 1.1 High-Speed Circuit Switched Data Networks.............. 3 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 2.0 Relay Agent Information Option......................... 6 2.1 Agent Operation........................................ 7 2.1.1 Reforwarded DHCP requests............................ 8 2.2 Server Operation....................................... 8 3.0 Relay Agent Information Suboptions..................... 9 3.1 Agent Circuit ID....................................... 9 3.2 Agent Remote ID........................................ 10 4.0 Issues Resolved........................................ 11 5.0 Security Considerations................................ 12 6.0 IANA Considerations.................................... 12 7.0 Intellectual Property Notice........................... 13 8.0 References............................................. 13 9.0 Glossary............................................... 14 10.0 Author's Address...................................... 14 Expires September 2000 [Page 2] March 2, 2000 Revision History Rev Date Description --- -------- ----------- -09 3/2/2000 Remove Subnet Mask suboption. It will be considered as a separate draft. -08 1/3/2000 Require that agents MUST NOT modify DHCP packets that use IPSEC. -07 8/24/99 Updated "Status of this memo" to conform to current I-D requirements. Revision -06 added section 7 Intellectual Property Notices. 1 Introduction 1.1 High-Speed Circuit Switched Data Networks Public Access to the Internet is usually via a circuit switched data network. Today, this is primarily implemented with dial-up modems connecting to a Remote Access Server. But higher speed circuit access networks also include ISDN, ATM, Frame Relay, and Cable Data Networks. All of these networks can be characterized as a "star" topology where multiple users connect to a "circuit access unit" via switched or permanent circuits. With dial-up modems, only a single host PC attempts to connect to the central point. The PPP protocol is widely used to assign IP addresses to be used by the single host PC. The newer high-speed circuit technologies, however, frequently provide a LAN interface (especially Ethernet) to one or more host PCs. It is desirable to support centralized assignment of the IP addresses of host computers connecting on such circuits via DHCP. The DHCP server can be, but usually is not, co-implemented with the centralized circuit concentration access device. The DHCP server is often connected as a separate server on the "Central LAN" to which the central access device (or devices) attach. A common physical model for high-speed Internet circuit access is shown in Figure 1, below. Expires September 2000 [Page 3] March 2, 2000 +---------------+ | Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A LAN | | Access | Lan |- Host B | | Unit 1 | |- Host C |-----| |-- | | |(relay agent) |... +---------+ | +---------------+ | DHCP |--| | Server | | +---------+ | | | +---------------+ +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D | Other | | | Access | Lan | Servers |--|-----| Unit 2 | | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E | DNS) | | |(relay agent) |... Lan | | +---------------+ +---------+ Figure 1: DHCP High Speed Circuit Access Model Note that in this model, the "modem" connects to a LAN at the user site, rather than to a single host. Multiple hosts are implemented at this site. Although it is certainly possible to implement a full IP router at the user site, this requires a relatively expensive piece of equipment (compared to typical modem costs). Furthermore, a router requires an IP address not only for every host, but for the router itself. Finally, a user-side router requires a dedicated Logical IP Subnet (LIS) for each user. While this model is appropriate for relatively small corporate networking environments, it is not appropriate for large, public accessed networks. In this scenario, it is advantageous to implement an IP networking model that does not allocate an IP address for the modem (or other networking equipment device at the user site), and especially not an entire LIS for the user side LAN. Note that using this method to obtain IP addresses means that IP addresses can only be obtained while communication to the central site is available. Some host lan installations may use a local DHCP server or other methods to obtain IP addresses for in-house use. Expires September 2000 [Page 4] March 2, 2000 1.2 DHCP Relay Agent in the Circuit Access Unit It is desirable to use DHCP to assign the IP addresses for public high-speed circuit access. A number of circuit access units (e.g. RAS's, cable modem termination systems, ADSL access units, etc) connect to a LAN (or local internet) to which is attached a DHCP server. For scaling and security reasons, it is advantageous to implement a "router hop" at the circuit access unit, much like high-capacity RAS's do today. The circuit access equipment acts as both a router to the circuits and as the DHCP relay agent. The advantages of co-locating the DHCP relay agent with the circuit access equipment are: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; The same mechanism used to identify the remote connection of the circuit (e.g. a user ID requested by a Remote Access Server acting as the circuit access equipment) may be used as a host identifier by DHCP, and used for parameter assignment. This includes centralized assignment of IP addresses to hosts. This provides a secure remote ID from a trusted source -- the relay agent. A number of issues arise when forwarding DHCP requests from hosts connecting publicly accessed high-speed circuits with LAN connections at the host. Many of these are security issues arising from DHCP client requests from untrusted sources. How does the relay agent know to which circuit to forward replies? How does the system prevent DHCP IP exhaustion attacks? This is when an attacker requests all available IP addresses from a DHCP server by sending requests with fabricated client MAC addresses. How can an IP address or LIS be permanently assigned to a particular user or modem? How does one prevent "spoofing" of client identifer fields used to assign IP addresses? How does one prevent denial of service by "spoofing" other client's MAC addresses? All of these issues may be addressed by having the circuit access equipment, which is a trusted component, add information to DHCP client requests that it forwards to the DHCP server. Expires September 2000 [Page 5] March 2, 2000 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Descrption Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option Expires September 2000 [Page 6] March 2, 2000 New sub-option codes MUST be assigned by IANA according to the policy described in the "IANA Considerations" section of this document. 2.1 Agent Operation Overall adding of the DHCP relay agent option SHOULD be configurable, and SHOULD be disabled by default. Relay agents SHOULD have separate configurables for each sub-option to control whether it is added to client-to-server packets. A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last DHCP agent option in the DHCP options field of any recognized DHCP packet forwarded from a client to a server. Such additions shall be made for only those packets recognized as DHCP; BOOTP-only packets shall not be affected. Relay agents receiving a DHCP packet with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count. Relay agents MAY have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets which, after appending the Relay Agent Information option, would exceed this configured maximum size shall be forwarded WITHOUT adding the Agent Information option. An error counter SHOULD be incremented in this case. In the absence of this configurable, the agent SHALL NOT increase a forwarded DHCP packet size to exceed the MTU of the interface on which it is forwarded. The Relay Agent Information option echoed by a server MUST be removed by the agent when forwarding a server-to-client response back to the client. The agent SHALL NOT add an "Option Overload" option to the packet or use the "file" or "sname" fields for adding Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in the sname or file fields of a server-to-client packet forwarded through the agent. The operation of relay agents for specific sub-options is specified with that sub-option. Relay agents are NOT required to monitor or modify client-originated DHCP packets addressed to a server unicast address. This includes the DHCP-REQUEST sent when entering the RENEWING state. Relay agents MUST NOT modify DHCP packets that use the IPSEC Expires September 2000 [Page 7] March 2, 2000 Authentication Header or IPSEC Encapsulating Security Payload [6]. 2.1.1 Reforwarded DHCP requests A DHCP relay agent may receive a client DHCP packet forwarded from a BOOTP/DHCP relay agent closer to the client. Such a packet will have giaddr as non-zero, and may or may not already have a DHCP Relay Agent option in it. Relay agents configured to add a Relay Agent option which receive a client DHCP packet with a nonzero giaddr SHALL discard the packet if the giaddr spoofs a giaddr address implemented by the local agent itself. Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value. 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation. The operation of DHCP servers for specific sub-options is specified with that sub-option. Note that DHCP relay agents are not required to monitor unicast DHCP messages sent directly between the client and server (i.e, those that aren't sent via a relay agent). However, some relay agents MAY chose to do such monitoring and add relay agent options. Consequently, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there. Expires September 2000 [Page 8] March 2, 2000 3.0 Relay Agent Information Sub-options 3.1 Agent Circuit ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for use by agents in relaying DHCP responses back to the proper circuit. Possible uses of this field include - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number Servers MAY use the Circuit ID for IP and other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server. The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. SubOpt Len Circuit ID +------+------+------+------+------+------+------+------+-- | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... +------+------+------+------+------+------+------+------+-- Expires September 2000 [Page 9] March 2, 2000 3.2 Agent Remote ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The remote ID MUST be globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server. The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client. SubOpt Len Agent Remote ID +------+------+------+------+------+------+------+------+-- | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... +------+------+------+------+------+------+------+------+-- Expires September 2000 [Page 10] March 2, 2000 4.0 Issues Resolved Broadcast Forwarding The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID. DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. Static Assignment The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID. IP Spoofing The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit to which it was forwarded. The circuit access device MAY prevent forwarding of IP packets with source IP addresses -other than- those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central LAN, and IP spoofing of other hosts. Client Identifer Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifer field need not be used by the DHCP server. Expires September 2000 [Page 11] March 2, 2000 MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. 5.0 Security Considerations DHCP as currently defined provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1]. This document introduces mechanisms to address several security attacks on the operation of IP address assignment, including IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion. It relies on an implied trusted relationship between the DHCP Relay Agent and the DHCP server, with an assumed untrusted DHCP client. It introduces a new identifer, the "Remote ID", that is also assumed to be trusted. The Remote ID is provided by the access network or modem and not by client premise equipment. Cryptographic or other techniques to authenticate the remote ID are certainly possible and encouraged, but are beyond the scope of this document. Note that any future mechanisms for authenticating DHCP client to server communications must take care to omit the DHCP Relay Agent option from server authentication calculations. This was the principal reason for organizing the DHCP Relay Agent Option as a single option with sub-options, and for requiring the relay agent to remove the option before forwarding to the client. While it is beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, note that automatic reforwarding of IP or ARP broadcast packets back downstream exposes serious IP security risks. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host may easily spoof the desired DHCP server. 6.0 IANA Considerations IANA is required to maintain a new number space of "DHCP Relay Agent Sub-options", with the initial sub-options as described in this document. IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF Consensus" policy as described in RFC 2434 [3]. Future proposed sub-options MUST be referenced symbolically in the internet-drafts that describe them, and shall be assigned numeric codes by IANA when Expires September 2000 [Page 12] March 2, 2000 and if the draft is approved by IESG for Proposed Standard RFC status. 7.0 Intellectual Property Notices This section contains two notices as required by [5] for standards track documents. Per [5], section 10.4(A): The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Per [5] section 10.4(D): The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 8.0 References Expires September 2000 [Page 13] March 2, 2000 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" RFC 2132. [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [5] Bradner, S. "The Internet Standards Process -- Revision 3", RFC 2026. [6] Kent, S. and Atkinson, R. "Security Architecture for the Internet Protocol", RFS 2401. 9.0 Glossary IANA Internet Assigned Numbers Authority LIS Logical IP Subnet MAC Message Authentication Code RAS Remote Access Server 10.0 Author's Address Michael Patrick Motorola Broadband Communications Sector 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048 Phone: (508) 261-5707 Email: mpatrick@dma.isg.mot.com Expires September 2000 [Page 14] From owner-dhcp-v4@bucknell.edu Thu Mar 2 09:22:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13492 for ; Thu, 2 Mar 2000 09:22:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA14390; Thu, 2 Mar 2000 09:22:13 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA15898 for ; Thu, 2 Mar 2000 09:21:44 -0500 (EST) Received: from droms-mac (pm3mi1-25.uplink.net [209.173.86.26]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA11890 for ; Thu, 2 Mar 2000 09:21:43 -0500 (EST) Message-Id: <4.2.2.20000302091501.00a4d2f0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 02 Mar 2000 09:17:01 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: DHCP client In-Reply-To: <38B5F6AD.4C928940@home.com> References: <20000224041538.30481.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is basically correct (I'm guessing you meant "DHCP server" in C). In D, the client can continue to use its IP address and participate in TCP sessions until the lease expires - even if the client is unable to contact a DHCP server. - Ralph Droms At 09:27 PM 2/24/00 -0600, Michael Schneider wrote: >Todd - > My WINTEL experience in this matter is thus: > >If: >A) Client receives lease (lease period is 90 days), and >B) DHCP server dies, and >C) DHCP stay dead for more than 90 days. >Then: >D) At each start up and at every decaying half-life interval, >the client will poll the nonexistent DHCP server for a renewal >of the lease it has. If the lease expires before the DHCP service >is restored, the client should lose its IP address, and continue >to periodically broadcast DHCP requests until it receives a response. From owner-dhcp-v4@bucknell.edu Thu Mar 2 09:25:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13600 for ; Thu, 2 Mar 2000 09:25:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA22310; Thu, 2 Mar 2000 09:25:07 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA00492 for ; Thu, 2 Mar 2000 09:21:46 -0500 (EST) Received: from droms-mac (pm3mi1-25.uplink.net [209.173.86.26]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA11893 for ; Thu, 2 Mar 2000 09:21:45 -0500 (EST) Message-Id: <4.2.2.20000302091820.00a6e940@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 02 Mar 2000 09:20:25 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: DHCP client In-Reply-To: <20000225044412.15294.qmail@web704.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I mostly agree with what you've written, except for the very last sentence: >So basically >your DHCP client computer will have a valid IP address >untill the lease expires, but it will not be able to >participate in a TCP/IP session. In the event that the DHCP client cannot contact a server, the client will have a valid address until the lease expires, and it *will* be able to use TCP (in fact, it can make full use of the entire TCP/IP suite). - Ralph Droms At 08:44 PM 2/24/00 -0800, Cody Smith wrote: > Mr.Schneider is exactly right in what he said, but >there is more. If a DHCP client is leased an IP >address for a certain time period that client will >keep the DHCP configuration information in its >registry. If upon startup the DHCP client does not >recieve a reply to its DHCPrequest message which is >sent out everytime the computer is restarted, it will >still hold the original lease in its registry. When >50% of the lease time expires the DHCP client will >request a DHCP lease renewal directly from the >originating DHCP server. When it cant find a DCHP >server it will keep on sending out DHCPrequest >messages directly to the server from where the lease >was first obtained, in certain specified intervals >which are as follows: >4 DHCPrequest messages in the first 5 minutes of >startup, and 1 DHCPrequest message every 5 minutes >thereafter. >When the 87.5% of the clients lease has expired, and >the DHCP client still cannot find the originating DHCP >server is will send out a DHCPdiscover message which >will basically broadcast to every DHCP server on the >subnet if there is more than one DHCP server. Keep in >mind while all this is happening the client still >holds on to that valid TCP/IP configuration(including >a valid IP address) in the registry. So basically >your DHCP client computer will have a valid IP address >untill the lease expires, but it will not be able to >participate in a TCP/IP session. > >Cody Smith >Network Administrator >US Army >FT. Lewis, WA 98433 > > > >===== >The only good is knowledge, and the only evil ignorance. >-Socrates >__________________________________________________ >Do You Yahoo!? >Talk to your friends online with Yahoo! Messenger. >http://im.yahoo.com From owner-dhcp-v4@bucknell.edu Thu Mar 2 10:33:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15226 for ; Thu, 2 Mar 2000 10:33:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA10238; Thu, 2 Mar 2000 10:32:46 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA05481 for ; Thu, 2 Mar 2000 10:32:09 -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 KAA15062; Thu, 2 Mar 2000 10:32:06 -0500 (EST) Message-Id: <200003021532.KAA15062@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-nsso-03.txt Date: Thu, 02 Mar 2000 10:32:06 -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 : The Name Service Search Option for DHCP Author(s) : C. Smith Filename : draft-ietf-dhc-nsso-03.txt Pages : 4 Date : 01-Mar-00 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-03.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-nsso-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-nsso-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000301084411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nsso-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nsso-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000301084411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Mar 2 13:09:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21569 for ; Thu, 2 Mar 2000 13:09:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA08772; Thu, 2 Mar 2000 13:08:39 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA18013 for ; Thu, 2 Mar 2000 13:08:21 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 13:07:50 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C9626@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Thu, 2 Mar 2000 13:07:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Note, btw, that access equipment that are bridges need not be >precluded from acting as relay agents, i.e. adding the agent option >as well as filling in giaddr. Hello Mike, What would be in the giaddr field in the above case? (Assuming it was not filled in prior). sG From owner-dhcp-v4@bucknell.edu Thu Mar 2 19:59:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02371 for ; Thu, 2 Mar 2000 19:59:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA22408; Thu, 2 Mar 2000 19:59:34 -0500 (EST) Received: from eclipse.4d.net (eclipse.4d.net [207.137.152.8]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA14351 for ; Thu, 2 Mar 2000 19:59:24 -0500 (EST) From: js-support@4dcomm.com Received: from 4dcomm.com (www.capsplacement.com [207.137.152.168] (may be forged)) by eclipse.4d.net (8.8.7/8.8.8) with SMTP id QAA06242 for ; Thu, 2 Mar 2000 16:59:23 -0800 (PST) Sender: owner-dhcp-v4@bucknell.edu Reply-to: js-support@4dcomm.com To: DHCPv4 discussion list Date: Thu, 2 Mar 100 16:59:14 -800 X-Mailer: DMailWebReg Web to Mail gateway 1.2d, http://netwinsite.com/top_mail.htm Message-id: <38bf0e62.ce2.0@4dcomm.com> X-User-Info: 204.216.240.98 X-Sender: js-support@4dcomm.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, there: A simple question, does DHCP update with DNS server for the full qualified domain name when it is assigned with a new address? I did not find the info from RFC 2131. (another question is: Does dial-up PPP implicitly use DHCP?) Thanks, Simon From owner-dhcp-v4@bucknell.edu Thu Mar 2 20:22:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02630 for ; Thu, 2 Mar 2000 20:22:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA12299; Thu, 2 Mar 2000 20:22:09 -0500 (EST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA15659 for ; Thu, 2 Mar 2000 20:21:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id UAA25721 for ; Thu, 2 Mar 2000 20:21:47 -0500 (EST) Date: Thu, 2 Mar 2000 20:21:47 -0500 (EST) From: "William A. Arbaugh" To: DHCPv4 discussion list Subject: New Authentication draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've attached a copy of the current draft to this message. If you have any last minute edits/comments, please do so before March 8th. Ralph and I will update and submit the draft by the deadline. Thanks to Bernie Volz, Kim Kinnear, and Richard Jones for providing comments/edits. Bill Network Working Group R. Droms, Editor INTERNET DRAFT Bucknell University Obsoletes: draft-ietf-dhc-authentication-12.txt W. Arbaugh, Editor WAA Associates, LLC. March 2000 Expires September 2000 Authentication for DHCP Messages Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt, and the list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. 1. Introduction DHCP [1] transports protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. Among those parameters are an IP address. DHCP servers can be configured to dynamically allocate addresses from a pool of addresses, eliminating Droms FORMFEED[Page 1] DRAFT Authentication for DHCP Messages March 2000 a manual step in configuration of TCP/IP hosts. Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls. This document defines a technique that can provide both entity authentication and message authentication. DISCUSSION: This draft combines the original Schiller-Huitema-Droms authentication mechanism () with the "delayed authentication" proposal developed by Bill Arbaugh. This draft has been published as a revision to . 1.1 DHCP threat model The threat to DHCP is inherently an insider threat (assuming a properly configured network where BOOTP ports are blocked on the enterprise's perimeter gateways.) Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same. The attack specific to a DHCP client is the possibility of the establishment of a "rogue" server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to establish a "man in the middle" attack or it may be for a "denial of service" attack. There is another threat to DHCP clients from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters. The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for "theft of service", or to circumvent auditing for any number of nefarious purposes. The threat common to both the client and the server is the resource "denial of service" (DoS) attack. These attacks typically involve the Droms FORMFEED[Page 2] DRAFT Authentication for DHCP Messages March 2000 exhaustion of valid addresses, or the exhaustion of CPU or network bandwidth, and are present anytime there is a shared resource. In current practice, redundancy mitigates DoS attacks the best. 1.2 Design goals These are the goals that were used in the development of the authentication protocol, listed in order of importance: 1. Address the threats presented in Section 1.1. 2. Avoid changing the current protocol. 3. Limit state required by the server. 4. Limit complexity (complexity breeds design and implementation errors). 1.3 Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 1.4 DHCP Terminology This document uses the following terms: o "DHCP client" A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. 2. Format of the authentication option The following diagram defines the format of the DHCP authentication option: Droms FORMFEED[Page 3] DRAFT Authentication for DHCP Messages March 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length | Protocol (2) |RDM| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Replay Detection (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Authentication Information ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The code for the authentication option is TBD, and the length field contains the length of the protocol, RDM, algorithm, Replay Detection fields and authentication information fields in octets. The protocol field defines the particular technique for authentication used in the option. New protocols are defined as decribed in Section 6. The Replay Detection Method (RDM) bit field determines the type of replay detection used in the Replay Detection Field. The following defines the possible values for the RDM: 00 The replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols. 01 Reserved to be defined as described in Section 6. 10 Reserved to be defined as described in Section 6. 11 Reserved to be defined as described in Section 6. The algorithm field defines the specific algorithm within the technique identified by the protocol field. The Replay Detection field is per the RDM, and the authentication information field is per the protocol in use. This document defines two protocols in sections 4 and 5, encoded with protocol field values 0 and 1. Protocol field values 2-254 are reserved for future use. Other protocols may be defined according to the procedure described in section 6. Droms FORMFEED[Page 4] DRAFT Authentication for DHCP Messages March 2000 3. Interaction with Relay Agents Because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST be set to zero for the computation of any hash function over the message header. Additionally, a relay agent may append the DHCP relay agent information option 82 [7] as the last option in a message to servers. If a server finds option 82 included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back option 82 to a relay agent, the server MUST not include the option in the computation of any hash function over the message. 4. Protocol 0 If the protocol field is 0, the authentication information field holds a simple authentication token: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 0|0 0|0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Replay Detection (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication token (n octets) ... + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The authentication token is an opaque, unencoded value known to both the sender and receiver. The sender inserts the authentication token in the DHCP message and the receiver matches the token from the message to the shared token. If the authentication option is present and the token from the message does not match the shared token, the receiver MUST discard the message. Protocol 0 may be used to pass a plain-text password and provides only weak entity authentication and no message authentication. This protocol is only useful for rudimentary protection against inadvertently instantiated DHCP servers. Droms FORMFEED[Page 5] DRAFT Authentication for DHCP Messages March 2000 DISCUSSION: The intent here is to pass a constant, non-computed token such as a plain-text password. Other types of entity authentication using computed tokens such as Kerberos tickets or one-time passwords will be defined as separate protocols. 5. Protocol 1 If the protocol field is 1, the message is using the "delayed authentication" mechanism. In delayed authentication, the client requests authentication in its DHCPDISCOVER message and the server replies with a DHCPOFFER message that includes authentication information information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication. This document defines the use of a particular technique based on the HMAC protocol [3] using the MD5 hash [2]. 5.1 Management Issues This protocol does not attempt to address situations where a client may roam from one administrative domain to another, i.e. interdomain roaming. This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared secret is feasible. 5.2 Format The format of the authentication request in a DHCPDISCOVER message for protocol 1 is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Replay Detection (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the authentication information for protocol 1 is: Droms FORMFEED[Page 6] DRAFT Authentication for DHCP Messages March 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Replay Detection (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | secret ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC-MD5 (128 bits) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document defines one technique for use with protocol 1, which is identified by setting the algorithm field to 1. Other techniques that use different algorithms may be defined by future specifications, see section 6. The following definitions will be used in the description of the authentication information for protocol 1, algorithm 1: Replay Detection - as defined by the RDM field K - a secret value shared between the source and destination of the message; each secret has a unique identifier (not shown in figures) secret ID - the unique identifier for the secret value used to generate the MAC for this message HMAC-MD5 - the MAC generating function [3, 2]. The sender computes the MAC using the HMAC generation algorithm [3] and the MD5 hash function [2]. The entire DHCP message (except as noted below), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC. DISCUSSION: Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol. Protocol 1 requires a shared secret key for each client on each DHCP server with which that client may wish to use the DHCP protocol. Each secret key has a unique identifier that can be used by a receiver to determine which secret was used to generate the MAC in the DHCP message. Therefore, protocol 1 may not scale Droms FORMFEED[Page 7] DRAFT Authentication for DHCP Messages March 2000 well in an architecture in which a DHCP client connects to multiple administrative domains. Note that the meaning of an authentication option can be changed by removing the secret ID, and MAC, transforming an authentication option with authentication information into a request for authentication. Therefore, the authentication request form of this option can only appear in a DHCPDISCOVER message. 5.3 Message validation To validate an incoming message, the receiver checks the RDM field and computes the MAC as described in [3]. If the 'counter' field does not contain a value larger than the last value of 'counter' used by the sender, the receiver MUST discard the incoming message. The receiver MUST set the 'MAC' field of the authentication option to all 0s for computation of the MAC, and because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the computation of the MAC. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message. Section 3 provides additional information on handling messages that include option 82 (Relay Agents). 5.4 Key utilization Each DHCP client has a key, K. The client uses its key to encode any messages it sends to the server and to authenticate and verify any messages it receives from the server. The client's key SHOULD be initially distributed to the client through some out-of-band mechanism, and SHOULD be stored locally on the client for use in all authenticated DHCP messages. Once the client has been given its key, it SHOULD use that key for all transactions even if the client's configuration changes; e.g., if the client is assigned a new network address. Each DHCP server MUST know, or be able to obtain in a secure manner, the keys for all authorized clients. If all clients use the same key, clients can perform both entity and message authentication for all messages received from servers. However, the sharing of keys is strongly discouraged as it allows for unauthorized clients to masquerade as authorized clients by obtaining a copy of the shared key. To authenticate the identity of individual clients, each client MUST be configured with a unique key. Appendix A describes a technique for key management. Droms FORMFEED[Page 8] DRAFT Authentication for DHCP Messages March 2000 5.5 Client considerations This section describes the behavior of a DHCP client using authentication protocol 1. 5.5.1 INIT state When in INIT state, the client uses protocol 1 as follows: 1. The client MUST include the authentication request option in its DHCPDISCOVER message along with option 61 [6] to identify itself uniquely to the server. 2. The client MUST validate any DHCPOFFER messages that include authentication information using the mechanism specified in section 5.3. The client MUST discard any messages which fail to pass validation and MAY log the validation failure. The client selects one DHCPOFFER message as its selected configuration. If none of the DHCPOFFER messages received by the client include authentication information, the client MAY choose an unauthenticated message as its selected configuration. The client SHOULD be configurable to accept or reject unauthenticated DHCPOFFER messages. 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message. 4. The client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server. 5.5.2 INIT-REBOOT state When in INIT-REBOOT state, the client MUST use the secret it used in its DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages if no authenticated messages were received. The client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK messages as specified in section 3.2 of [1]. 5.5.3 RENEWING state When in RENEWING state, the client uses the secret it used in its Droms FORMFEED[Page 9] DRAFT Authentication for DHCP Messages March 2000 initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1]. 5.5.4 REBINDING state When in REBINDING state, the client uses the secret it used in its initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1]. 5.5.5 DHCPINFORM message Since the client already has some configuration information, the client may also have established a shared secret value, K, with a server. Therefore, the client SHOULD use the authentication request as in a DHCPDISCOVER message when a shared secret value exists. The client MUST treat any received DHCPACK messages as it does DHCPOFFER messages, see section 5.5.1. 5.5.6 DHCPRELEASE message Since the client is already in the BOUND state, the client will have a security association already established with the server. Therefore, the client MUST include authentication information with the DHCPRELEASE message. 5.6 Server considerations This section describes the behavior of a server in response to client messages using authentication protocol 1. 5.6.1 General considerations Each server maintains a list of secrets and identifiers for those secrets that it shares with clients and potential clients. This information must be maintained in such a way that the server can: * Identify an appropriate secret and the identifier for that secret for use with a client that the server may not have previously communicated with * Retrieve the secret and identifier used by a client to which the Droms FORMFEED[Page 10] DRAFT Authentication for DHCP Messages March 2000 server has provided previous configuration information Each server MUST save the counter from the previous authenticated message. A server MUST discard any incoming message which fails the replay detection check as defined by the RDM avoid replay attacks. DISCUSSION: The authenticated DHCPREQUEST message from a client in INIT- REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER messages. Other servers will discard the DHCPREQUEST messages. Thus, only servers that used the secret selected by the client will be able to determine that their offered configuration information was not selected and the offered network address can be returned to the server's pool of available addresses. The servers that cannot validate the DHCPREQUEST message will eventually return their offered network addresses to their pool of available addresses as described in section 3.1 of the DHCP specification [1]. 5.6.2 After receiving a DHCPDISCOVER message The server selects a secret for the client and includes authentication information in the DHCPOFFER message as specified in section 5, above. The server MUST record the identifier of the secret selected for the client and use that same secret for validating subsequent messages with the client. 5.6.3 After receiving a DHCPREQUEST message The server uses the secret identified in the message and validates the message as specified in section 5.3. If the message fails to pass validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure. If the message passes the validation procedure, the server responds as described in the DHCP specification. The server MUST include authentication information generated as specified in section 5.2. 5.6.4 After receiving a DHCPINFORM message The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated DHCPINFORM messages based on a site policy. Droms FORMFEED[Page 11] DRAFT Authentication for DHCP Messages March 2000 When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message. If the server does not have a shared secret value established with the sender of the DHCPINFORM message, then the server MAY respond with an unauthenticated DHCPACK message, or a DHCPNACK if the server does not accept unauthenticated clients based on the site policy. 6. IANA Considerations The author of a new DHCP option will follow these steps to obtain acceptance of the protocol as a part of the DHCP Internet Standard: 1. The author devises the new authentication protocol and/or algorithm. 2. The author documents the new technique as an Internet Draft. If this is a new protocol, the protocol code is left as "To Be Determined" (TBD); otherwise, the protocol code is the code from the existing protocol. The algorithm code is left as "TBD". 3. The author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" (STD 1). 4. The new protocol progresses through the IETF standards process; the specification of the new protocol will be reviewed by the Dynamic Host Configuration Working Group (if that group still exists), or as an Internet Draft not submitted by an IETF working group. If the option is accepted as a Standard, the specification for the option is published as a separate RFC. 5. At the time of acceptance as a Proposed Internet Standard and publication as an RFC, IANA assigns a DHCP authentication protocol number to the new protocol. This procedure for defining new authentication protocols will ensure that: * allocation of new protocol numbers is coordinated from a single authority, * new protocols are reviewed for technical correctness and appropriateness, and * documentation for new protocols is complete and published. DISCUSSION: This procedure is patterned after the procedure for acceptance of new DHCP options. Droms FORMFEED[Page 12] DRAFT Authentication for DHCP Messages March 2000 7. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC-2104, February 1997. [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 1992. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC-2219, March 1997. [6] Henry, M., "DHCP Option 61 UUID Type Definition," (work in progress, November 1998. [7] Patrick, M., "DHCP Relay Agent Information Option," (work in progress), November 1998. [8] Gupta, V., "Flexible Authentication for DHCP Messages," (work in progress, June 1998. 8. Acknowledgments Jeff Schiller and Christian Huitema developed this scheme during a terminal room BOF at the Dallas IETF meeting, December 1995. The editor transcribed the notes from that discussion, which form the basis for this document. The editor appreciates Jeff's and Christian's patience in reviewing this document and its earlier drafts. The "delayed authentication" mechanism used in section 5 is due to Bill Arbaugh. The threat model and requirements in sections 1.1 and 1.2 come from Bill's negotiation protocol proposal. The attendees of an interim meeting of the DHC WG held in June, 1998, including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and Arun Kapur, developed the threat model and reviewed several alternative proposals. Droms FORMFEED[Page 13] DRAFT Authentication for DHCP Messages March 2000 The replay detection method field is due to Vipul Gupta [8]. Other input from Bill Sommerfield is gratefully acknowledged. Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document. 9. Security considerations This document describes authentication and verification mechanisms for DHCP. 10. Editors' addresses Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu William Arbaugh WAA Associates, LLC. 4264 Hermitage Dr. Ellicott City, MD. 21042 Phone: (410) 465-2740 EMail: waa@home.com 10. Expiration This document will expire on September 30, 2000. Droms FORMFEED[Page 14] DRAFT Authentication for DHCP Messages March 2000 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. Droms FORMFEED[Page 15] DRAFT Authentication for DHCP Messages March 2000 Appendix A - Key Management Technique To avoid centralized management of a list of random keys, suppose K for each client is generated from the pair (client identifier [6], subnet address, e.g. 192.168.1.0), which must be unique to that client. That is, K = MAC(MK, unique-id), where MK is a secret master key and MAC is a keyed one-way function such as HMAC-MD5. Without knowledge of the master key MK, an unauthorized client cannot generate its own key K. The server can quickly validate an incoming message from a new client by regenerating K from the client-id. For known clients, the server can choose to recover the client's K dynamically from the client-id in the DHCP message, or can choose to precompute and cache all of the Ks a priori. NOTE: While this key management mechanism avoids the problem of managin a large list of secret keys, it does allow any client to masquerade as another client since the client identifier will be sent in the clear. Droms FORMFEED[Page 16] From owner-dhcp-v4@bucknell.edu Thu Mar 2 21:00:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03010 for ; Thu, 2 Mar 2000 21:00:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA19268; Thu, 2 Mar 2000 21:00:45 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id VAA14303 for ; Thu, 2 Mar 2000 21:00:25 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id RAA10529; Thu, 2 Mar 2000 17:57:29 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id RAA02977; Thu, 2 Mar 2000 17:58:21 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id <1RRJLJ9K>; Thu, 2 Mar 2000 17:57:54 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75ABA@msgsrv04.srv.pacbell.com> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: Date: Thu, 2 Mar 2000 17:57:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From: js-support@4dcomm.com[SMTP:js-support@4dcomm.com] > > does DHCP update with DNS server for > the full qualified domain name when it is assigned with > a new address? I did not find the info from RFC 2131. > (another question is: Does dial-up PPP implicitly use > DHCP?) > ...RFC2131 does not specify DNS updates. That is currently under discussion as an Internet-Draft by Yakhov Rekhter and Mark Stapp. From owner-dhcp-v4@bucknell.edu Fri Mar 3 06:27:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22603 for ; Fri, 3 Mar 2000 06:27:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA01998; Fri, 3 Mar 2000 06:27:16 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA21718 for ; Fri, 3 Mar 2000 06:27:02 -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 GAA22490; Fri, 3 Mar 2000 06:27:00 -0500 (EST) Message-Id: <200003031127.GAA22490@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-agent-options-09.txt Date: Fri, 03 Mar 2000 06:26:56 -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 Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-09.txt Pages : 14 Date : 02-Mar-00 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-09.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-agent-options-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-options-09.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: <20000302145829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-options-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000302145829.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 3 06:45:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22965 for ; Fri, 3 Mar 2000 06:45:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA01853; Fri, 3 Mar 2000 06:45:50 -0500 (EST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA08052 for ; Fri, 3 Mar 2000 06:45:30 -0500 (EST) Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id MAA22738 for ; Fri, 3 Mar 2000 12:44:54 +0100 (MET) Received: from btmq9z.rc.bel.alcatel.be (btmq9z [138.203.65.192]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id MAA18141 for ; Fri, 3 Mar 2000 12:44:49 +0100 (MET) Received: (from schrijvp@localhost) by btmq9z.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) id MAA09850 for dhcp-v4@bucknell.edu; Fri, 3 Mar 2000 12:44:49 +0100 (MET) Date: Fri, 3 Mar 2000 12:44:49 +0100 From: De Schrijver Peter To: DHCPv4 discussion list Subject: New version of draft-schrijvp-dhcpv4-reconfigure-01.txt Message-ID: <20000303124449.C9696@rc.bel.alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Reply-To: schrijvp@rc.bel.alcatel.be Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, Please find attached a new version of draft-ietf-dhcpv4-reconfigure-01.txt. Ralph : Could you also reserve a 10 minutes slot on the Adelaide DHC meeting ? Peter & Yves. From owner-dhcp-v4@bucknell.edu Fri Mar 3 06:48:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23027 for ; Fri, 3 Mar 2000 06:48:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA22185; Fri, 3 Mar 2000 06:48:51 -0500 (EST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA31933 for ; Fri, 3 Mar 2000 06:48:39 -0500 (EST) Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id MAA23263 for ; Fri, 3 Mar 2000 12:48:05 +0100 (MET) Received: from btmq9z.rc.bel.alcatel.be (btmq9z [138.203.65.192]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id MAA18303 for ; Fri, 3 Mar 2000 12:47:59 +0100 (MET) Received: (from schrijvp@localhost) by btmq9z.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) id MAA09889 for dhcp-v4@bucknell.edu; Fri, 3 Mar 2000 12:47:59 +0100 (MET) Date: Fri, 3 Mar 2000 12:47:59 +0100 From: De Schrijver Peter To: DHCPv4 discussion list Subject: New version of draft-ietf-dhcpv4-reconfigure-01.txt Message-ID: <20000303124759.D9696@rc.bel.alcatel.be> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=qlTNgmc+xy1dBmNv X-Mailer: Mutt 0.95.5i Reply-To: schrijvp@rc.bel.alcatel.be Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Hi, Hopefully this time with attachment :) Peter & Yves --qlTNgmc+xy1dBmNv Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-dhcpv4-reconfigure-01.txt" Submitted to DHC Working Group Peter De Schrijver INTERNET DRAFT Yves T'Joens Christian Hublet Alcatel March 2000 Expires September 2000 Dynamic host configuration : DHCP reconfigure extension Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. 1. Introduction The procedures as described within this draft allow the dynamic reconfiguration of individual hosts. De Schrijver, et al. Expires July 2000 [Page 1] Internet Draft draft-ietf-dhcpv4-reconfigure-01 March 2000 1.1 Conventions 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 [RFC2119]. 2. DHCP force renew This section describes the DHCP force renew extension. 2.1 Terminology DHCP client : host to be reconfigured using DHCP. DHCP server : server which configured the DHCP client. 2.2 Force renew procedures The DHCP server sends a force renew message to the client. The client will change its state to the RENEW state. The client will then try to renew its lease according to normal DHCP procedures. If the server wants to assign a new IP address to the client, it will reply to the DHCP REQUEST with a DHCP NAK. The client will then go back to the init state and broadcast a DHCP DISCOVER message. The server can now assign a new IP address to the client by replying with a DHCP OFFER. If the force renew message is lost, the DHCP server will not receive a DHCP REQUEST from the client and it should retransmit the DHCP FORCERENEW message using an exponential backoff algorithm. Depending on the bandwidth of the network between server and client, the server should choose a delay. This delay grows exponentially as retransmissions fail. The amount of retransmissions should be limited. 2.3 Rationale This approach has a number of advantages. It does not require new states to be added to the DHCP client implementation. This minimizes the amount of code to be changed. It also allows lease RENEWAL to be driven by the server, which can be used to optimize network usage or DHCP server load. 3. Extended DHCP state diagram De Schrijver, et al. Expires July 2000 [Page 2] Internet Draft draft-ietf-dhcpv4-reconfigure-01 March 2000 +--------+ +------+ | Init / | +-->+ Init +<---------------+-------------------+ | Reboot | | +--+---+ | | +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | | Restart | (broadcast) | | | | v v-------------+ | | -/Send DHCPREQUEST | +----+------+ DHCPOFFER/DHCPDECLINE | | (broadcast) | | Selecting |----------+ | | v | +----+------+ | | +---+----+ | DHCPOFFER/DHCPREQUEST | | | Reboot +--------------+ (broadcast) | | +---+----+ v | | | +----+-------+ DHCPNAK /halt network | + Requesting | | lease expired DHCPACK/ +----+-------+ | | Record lease | | | set timers DHCPACK/Record lease | | | v Set T1 & T2 | | | +--+----+DHCPFORCE +---+---+ +---+----+ +---------------------->+ Bound +---------->+ Renew +---------->+ Rebind | +--+-+--+T1 expires +-+-+---+ T2 expires+--+--+--+ ^ /DHCPREQUEST | | /broadcast | DHCPACK to leasing | | DHCPREQUEST | | server | | | +------------------------------------------+ 4. Message layout Field DHCPFORCERENEW ----- --------------- 'op' BOOTREPLY 'htype' (From "Assigned Numbers" RFC) 'hlen' (Hardware address length in octets) 'hops' 0 'xid' selected by server 'secs' 0 'ciaddr' 0 'yiaddr' 0 'siaddr' 0 'flags' 0 'giaddr' 0 'chaddr' client's hardware address 'sname' 0 'file' 0 'options' options DHCP option 53 (DHCP message type) is extended with a new value : De Schrijver, et al. Expires July 2000 [Page 3] Internet Draft draft-ietf-dhcpv4-reconfigure-01 March 2000 DHCPFORCERENEW 5. Failover Considerations A DHCP server should only send a DHCPFORCERENEW when it's fully aware of the current state of the DHCP client. In practice this means it should only send a DHCPFORCERENEW when in "PARTNER DOWN", "COMMUNICATIONS INTERRUPTED" or "NORMAL" state, and only for DHCP clients of which the state is synchronised. 6. IANA Considerations A new value for DHCP option 53 (DHCP message type) should be added to indicate a DHCPFORCERENEW message. 7. Security Considerations Depending on layer 2 characteristics, DHCP force renew can be used to snoop and spoof traffic. To prevent this, the DHCPFORCERENEW message should be authenticated using a shared secret based mechanism as described in [DHCP-AUTH]. 8. References [DHCP] R.Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [DHCP-AUTH] R. Droms, "Authentication for DHCP Messages", draft- ietf-dhc-euthentication-12, October 1999. 9. Contacts Peter De Schrijver Alcatel Corporate Research Center Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 8569 E-mail : peter.de_schrijver@alcatel.be Yves T'joens Alcatel Corporate Research Center Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 7890 E-mail : yves.tjoens@alcatel.be Christian Hublet Alcatel Carrier Internetworking Division De Villermontstraat 28, 2550 Kontich, Belgium De Schrijver, et al. Expires July 2000 [Page 4] Internet Draft draft-ietf-dhcpv4-reconfigure-01 March 2000 Phone : +32 3 450 3322 E-mail : Christian.Hublet@alcatel.be De Schrijver, et al. Expires July 2000 [Page 5] --qlTNgmc+xy1dBmNv-- From owner-dhcp-v4@bucknell.edu Fri Mar 3 09:04:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27174 for ; Fri, 3 Mar 2000 09:04:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA15458; Fri, 3 Mar 2000 09:04:37 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA30409 for ; Fri, 3 Mar 2000 09:04:32 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA20829; Fri, 3 Mar 2000 07:04:30 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA00861; Fri, 3 Mar 2000 07:04:28 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id JAA29487; Fri, 3 Mar 2000 09:04:25 -0500 (EST) Message-Id: <200003031404.JAA29487@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-reply-to: Your message of "Thu, 02 Mar 2000 13:07:50 EST." <63D30D6E10CFD11190A90000F805FE86023C9626@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Mar 2000 09:04:25 -0500 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > >Note, btw, that access equipment that are bridges need not be > >precluded from acting as relay agents, i.e. adding the agent option > >as well as filling in giaddr. > > > Hello Mike, > > What would be in the giaddr field in the above case? > (Assuming it was not filled in prior). > > sG > The bridge would be acting as a host of an IP subnet of the segments it bridges. The giaddr would be this host address. -mike From owner-dhcp-v4@bucknell.edu Fri Mar 3 12:55:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04667 for ; Fri, 3 Mar 2000 12:55:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA03737; Fri, 3 Mar 2000 12:54:04 -0500 (EST) Received: from fs-sd-exch1.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA29924 for ; Fri, 3 Mar 2000 12:53:36 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Mar 2000 09:52:27 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B10891599A00C@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Fri, 3 Mar 2000 09:52:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Comments embedded. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Michael W. Patrick [mailto:mpatrick@dma.isg.mot.com] > Sent: Thursday, March 02, 2000 2:48 > To: emichelsen@coppermountain.com > Cc: DHCPv4 discussion list; mpatrick@dma.isg.mot.com > Subject: Re: WG Last Call for "DHCP Relay Agent Information > Option" I-D ... > >> -----Original Message----- From: Eric Michelsen Sent: Wednesday, > >> February 23, 2000 9:14 To: 'dhcp-v4@bucknell.edu' Subject: > >> agent-options-08 > >> > >> > >> Why the prohibition against modifying BOOTP requests (sec 2.1, par > >> 2)? The clients may be old, and may issue BOOTP instead of DHCP. > >> Since the Agent-information is for the benefit of the access device > >> and the DHCP server, why disrupt existing deployments of BOOTP > >> clients, when the agent and server don't care? > > The relay agent would have to do a lot more than just add the > agent options; it would have to *change* the BOOTP to a DHCP by > adding the magic number. It wouldn't know, of course, critical > other DHCP-only info like client ID. Changing BOOTP to DHCP is > a big can of worms we can discuss separately but not something to > add in at the last minute here. I don't see any reason why the agent would have to change BOOTP to DHCP. The "agent-information" option is like almost every other option: it applies equally to DHCP and BOOTP. Relay-agents today handle both DHCP and BOOTP requests all the time. This requires no special effort or work on their part. The relay-agent function is identical for both protocols. > > >> > >> As an access equipment vendor, I have several scenarios where the > >> access equipment has the knowledge of Circuit ID, etc., but is not > >> acting at a protocol layer that allows it to actually *be* a DHCP > >> relay agent. These applications require that upstream Relay Agents > >> accept requests where the "agent-information" is present, but > >> giaddr = 0. Because servers and agents "know" if they require > >> circuit IDs or not, I don't see any security benefit to requiring > >> *relay agents* to discard such requests (sec 2.1, par 3). A better > >> statement would be that "devices inserting 'agent-information' must > >> remove any pre-existing 'agent-information', to prevent spoofing." > > We've discussed anti-spoofing in the WG, including, for instance, > "layering" multiple relay agent options. We've decided to keep the > principle that "he that relays adds giaddr". That is, either both > are added or neither. This is a restatement of the draft, but it is not enforceable, and not necessary. The forwarding agents in my example have no IP addresses (a configuration nightmare in the DSL scenario). As a malicious client, I can put in my own giaddr, spoof any other fields I want, and send a request up to the server. The network must protect itself against such attacks. As such, forwarding agents won't care whether giaddr is filled in or not. They will either discard invalid packets, or replace the bogus information. Either way, the upstream relay agents know from network topology that the request is valid and spoof-proof. They can confidently perform their normal relay-agent function. I have been participating in the DSL Forum's auto-configuration working group, and this is a very real requirement. ... > >> > >> The intent of sec 2.1, par 6 is not clear to me: why would the > >> sname or file fields have agent-information options in them, and > >> why shouldn't the access device remove them? > > Using "option overload" significantly complicated the logic, > (and so programming and testing) for adding options. It was felt to > be an unnecessary complication, and so it is precluded. Is this a special case for the agent-information option? I don't see how "agent-information" is different from any other DHCP/BOOTP option in that respect. I don't see how any logic is complicated for this option differently than for any other option. Can you elaborate? ... > >> > >> Sec 3.2, I think the "remote-ID" should be clarified, for the case > >> of PVC-like connections to the premise (e.g., DSL), the remote-ID > >> may be an identifier of the physical line (essentially, all the > >> circuit-ID suggestions, plus the additional suggestions given). > >> From the descriptions, it seems like servers interpret remote-ID as > >> the definitive client identification, and circuit-ID may be > >> interesting, but not necessarily definitive. > > I'm hesitant to add the language "definitive client identification". > I can imagine a DSL scenario, say, where the "definitive client > identification" is pre-assigned ATM VC IDs in the DSLAM. In this case, > the circuit ID is the option to be used by the server, because the > remote ATM "caller ID" wouldn't be known from SVC signalling. > I already give "ATM virtual circuit number" as one of the choices > of the circuit ID. There is an ambiguity that leads to interoperability problems: I'm a DHCP server, I receive a request with both the remote-ID and circuit-ID options. Which one do I use to securely identify the source of the request? In contrast, client-ID is defined as *the* unique identifier for a Server to index its database. The agent-options option needs a similar definitive statement of the Server's interpretation of the sub-options. From owner-dhcp-v4@bucknell.edu Fri Mar 3 14:54:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07615 for ; Fri, 3 Mar 2000 14:54:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA26615; Fri, 3 Mar 2000 14:52:10 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA01610 for ; Fri, 3 Mar 2000 14:52:03 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 14:51:29 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C962F@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-userclass-05.txt Date: Fri, 3 Mar 2000 14:51:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, I believe the N and Ln fields should be 2 byte fields. It is quite possible, that the individual class values end up longer than 255 esp. if the values are generated by some ticket issuing authority / self-registration server. (In practice, these class values may end up being certificates, or some simpler authenticated tickets). Also, it would be quite useful to include start and end time subfields for each class value. (Something like time_t formatted UTC values... 32 bit NBO etc.. etc..) The obvious use of the end time is to provide a ttl for the ticket (a.k.a class x ) and the start time could be used for reserving resources for a specific time slot. E.g.: to schedule a video conference ahead of time. /Steve Gonczi Process Software Corporation From owner-dhcp-v4@bucknell.edu Fri Mar 3 15:51:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08837 for ; Fri, 3 Mar 2000 15:51:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA00101; Fri, 3 Mar 2000 15:51:11 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA01575 for ; Fri, 3 Mar 2000 15:50:30 -0500 (EST) Received: from earth.research.telcordia.com (earth [192.4.18.66]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA16380 for ; Fri, 3 Mar 2000 15:49:55 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <38C02562.D8E5CE42@earth.research.telcordia.com> Date: Fri, 03 Mar 2000 15:49:54 -0500 From: Tony McAuley Organization: Telcordia X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: new dhcp enhancement requirements draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com X-Sender: mcauley@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Please find attached a new draft draft-ietf-dhc-enhance-requirements-00.txt We'd appreciate any comments and suggestions on this draft. Thanks Tony & Subir Network Working Group Anthony McAuley INTERNET-DRAFT Subir Das Internet Engineering Task Force Telcordia Technologies draft-ietf-dhc-enhance-requirements-00.txt Shinichi Baba Date: March 3, 2000 Yasuro Shobatake Expires: August 3, 2000 Toshiba America Research Inc. Requirements for Extending DHCP into New Environments Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of sections 10 of RFC 2026. 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 The Dynamic Host Configuration Protocol (DHCP) provides a widely deployed framework for host registration and configuration [DHC]. DHCP, however, was designed only for fixed hosts on physically secure LANs. Other protocols fill some of the gap. PPP [PPP] is a good solution for many commercial service providers (where framing is needed). Mobile IP [MIP] is ideal for registering and configuring roaming users (when transparent address binding is needed). This still leaves many environments where there is no ideal solution, such as: roaming users who do not need transparent address binding ITSUMO Group Expires August 2000 [Page 1] Internet Draft Requirements for Extending DHCP March 3, 2000 (e.g., a mobile web browser), and commercial service providers who want to support home networking with multiple nodes. This draft proposes DHCP as the best protocol to meet these new needs, because it leave open how (and whether) to provide other functions, such as framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or address distribution (e.g., [DAAP]). We describe and solicit feedback on seven new requirements that would be placed on DHCP to meet these needs. 1. Introduction Most future networks will use IP technology. To provide heterogeneity and flexibility, devices will likely access this IP-based network by directly sending IP packets. In such an environment it is natural to consider using IP-based protocols for user-network signaling, since they can be used across any wired or wireless access network. 1.1 Architecture Figure 1 shows a high level functional architecture of a future IP- based network, with both a fixed and a roaming clients attaching to various wired or wireless Access Networks. We assume the client has at least one physical interface onto the access network, but can also have other physical and virtual interfaces. The access network, which may contain multiple Layer 2 nodes (such as hubs), connects to at least one Edge Router and Edge Agent (that may be co-located). The Regional Backbone connects all the Edge Routers in an administrative domain and the Global Internet interconnects all the regional networks. We assume the network may need to change client configuration of even fixed nodes at any time, but that typically clients keep the same configuration (e.g., IP address) while they are within a given access network. Micro mobility within the access network is handled at Layer 2. Depending on how routing is done, the client may or may not need a new configuration when it moves to a new access network within the same domain (macro mobility) [CEL] [HAW]. We assume, however, that clients must be reconfigured when moving to a new domain (global mobility). ITSUMO Group Expires August 2000 [Page 2] Internet Draft Requirements for Extending DHCP March 3, 2000 . <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> . . +---------+ . +--------------+ . +---------+ . . | Domain | . | Inter-domain | . | Domain | . . | Agent | . | Agent | . | Agent | . . +---------+ . +--------------+ . +---------+ . . | . | . | . . __|__ . __|___ . __|__ . . / \ . / \ . / \ . . / \ . / \ . / \ . . / Regional\________/ Global \_________/ Regional\ . . \ Backbone/ . \ Internet / . \ Backbone/ . . ____\ /____ . \ / . ____\ /____ . . / \_____/ \ . \______/ . / \_____/ \ . . / | \ . . / | \ . . / | \ . . / | \ . . +--------+ . . +--------+ . . .. | Edge | .. . . .. | Edge | .. . . | Router | . . | Router | . . +--------+ . . +--------+ . . .. | | .. . . .. | | .. . . +--------+ | | +--------+ . . +--------+ | | +--------+ . . | Edge | | | | Edge | . . | Edge | | | | Edge | . . | Agent | | | | Agent | . . | Agent | | | | Agent | . . +--------+ | | +--------+ . . +--------+ | | +--------+ . . | | | | . . | | | | . . | _____ | | _____ | . . | _____ | | _____ | . . |/ \__| |__/ \| . . |/ \__| |__/ \| . . / \ / \ . . / \ / \ . . / Access \ .. / Access \ . . / Access \ .. / Access \ . . \ Network / \ Network / . . \ Network / \ Network / . . \ / \ / . . \ / \ / . . \_____/ \_____/ . . \_____/ \_____/ . . | | . . | | . | | | | +---------+ +---------+ global macro | Fixed | | Mobile | ****************> *************> | Client | | Client | mobility mobility +---------+ +---------+ Figure 1: Functional Network Architecture ITSUMO Group Expires August 2000 [Page 3] Internet Draft Requirements for Extending DHCP March 3, 2000 Figure 1 is meant to be very general functional diagram. It does not, for example, specify where a Base Station (BS) is located. BSs could be within the access networks (Layer 2 BS) or in the Edge Router (IP BS). The Domain and Inter-Domain agents which perform functions such as registration and AAA, are shown as single boxes; but both could be implemented as multiple nodes (possibly in a hierarchical structure). 1.2 Functional Scope The functions needed to support users' accessing IP-based networks vary, depending on network, user, and application characteristics. Some basic functions include: o Registration: Users indicate their presence and their requirements to a network (e.g., give a user name [NAI]). o Configuration: Networks adapt nodes to the particular network characteristics (e.g., give an IP address). o Framing: Indicates the start and end of packets in a data stream. o Compression: Compress RTP/UDP/TCP/IP header and data over an access network. o Dynamic Address Binding: Allows corresponding nodes to locate users and allows continuous communication as the user moves among networks. This draft is concerned only with the first two functions, which we believe have a natural association (see Section 3.5). This draft considers only server based methods for registration and configuration within a single IP domain. The network servers are themselves configured with information such as an IP address pool; but, server configuration is beyond the scope of this draft. We assume each access network has at least one edge server (possibly co-located with the edge router), though it could be as simple as a relay agent. 1.3 Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ]. ITSUMO Group Expires August 2000 [Page 4] Internet Draft Requirements for Extending DHCP March 3, 2000 1.4 Terminology This document uses the following terms: o "AAA" Authentication, authorization and accounting o "BOOTP" The Bootstrap Protocol (BOOTP) [BOO1] [BOO2]. o "DHCP" The Dynamic Host Configuration Protocol (DHCP) used to configure Internet hosts. o "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP relay agent" A relay agent is an Internet host that passes DHCP messages between DHCP clients and DHCP servers. o "DHCP server" A DHCP server is an Internet node that returns configuration parameters to DHCP clients. o "Domain Agent" An Internet node that provides a centralized service within a domain (e.g., DHCP server) o "Edge Router" An IP router connecting an IP subnet to other networks. o "Edge Agnet" An IP node (host or router) that is connected to an IP subnet and provides services (e.g., DHCP relay agent). o "Inter-domain Agent" An Internet node that provides services for a node anywhere in the Internet. o "NAI" Network Access Identifier of the form user@domain [NAI]. ITSUMO Group Expires August 2000 [Page 5] Internet Draft Requirements for Extending DHCP March 3, 2000 2 Registration and Configuration Protocols There are several TCP/IP protocol choices for performing registration and configuration: o The Point-to-Point Protocol (PPP). o The Mobile IP protocol (MIP). o The Dynamic Host Configuration Protocol (DHCP). 2.1 PPP Although its primary function is packet framing, PPP also provides well tested and widely deployed registration and configuration capabilities. PPP [PPP] clients sends registration information, such as login and password to an access concentrator on the Layer 2 network to which the client is connected. The access concentrator can then either directly configure the client or use the Layer 2 Tunneling Protocol [PPPL] to tunnel PPP packets to and from a server anywhere in the Internet. The powerful PPP registration and configuration capabilities are now even used when framing is not needed (e.g., PPPoE [PPPE]). The only cost is that it leaves some of the PPP framing overhead (2 bytes for framing, 2 bytes for CRC, up to 4 other bytes, and bit or byte stuffing overhead). 2.2 Mobile IP Although its primary function is providing location service and continuous connectivity to roaming users, Mobile IP [MIP] [MIP6] also provides a flexible registration and configuration capabilities. The Mobile IP client sends registration information to a Foreign Agent [MIPA] [MIPC] [MIPD] [MIPN] [MIPS] [MIPT] on the Layer 2 network to which the client is connected. The Foreign Agent can then configure the client, after getting authorization from the user's Home Agent. The registration and configuration capabilities could be provided by Mobile IP for all roaming users, even when transparent binding is not needed (e.g., for web browsing) or may need alternative mechanisms (viz., SIP for real-time applications [SIP] [SIPM]). The only costs are: a) triangular routing, b) having to configure a permanent home address, and c) depending on a home network. ITSUMO Group Expires August 2000 [Page 6] Internet Draft Requirements for Extending DHCP March 3, 2000 2.3 DHCP DHCP provides a well tested and widely deployed framework for passing configuration information to hosts [DHC]. A DHCP client in a host broadcasts a DISCOVER control message to the access network. A server picks up the message and either a) returns an OFFER message (server) or b) relays the message to a central DHCP server. DHCP is unique in that it: o Has no additional functions (e.g., framing or address binding). o Requires no client preconfiguration (e.g., for home addresses). o No overhead to data traffic (out-of-band signaling). o Allows nodes to go on and off without re-registration. o Allows a single network server per domain (using relay agents). DHCP is likely to continue to gain in popularity with recent enhancements, such as Server fail-over [DHCF], Load balancing [DHCB], Dynamic updating of DNS [DHCD], LDAP database management [DHCL], and Authentication [DHCA]. 2.4 Choice PPP, Mobile IP and DHCP were designed for different environments. Thus, network designers select the registration and configuration protocol that best fits the types of access network and likely client applications. For example, networks using phone lines for access will typically use PPP; wireless providers supporting roaming TCP application, such as telnet and ftp, will use Mobile IP; and corporate networks will use DHCP. The open question is what registration and configuration protocol will be used in environments that do not fit into the PPP, Mobile IP, or DHCP assumptions? Examples of these environments are: o Commercial service providers who want to support flexible home networking. o Roaming users who either do not need transparent binding (e.g., just web browsing) or prefer alternative mechanisms (e.g., SIP for real-time applications). PPP, Mobile IP and DHCP could all be adapted to better some or all of these environments. This draft proposes DHCP as the best protocol to meet these new needs, because it leave open how (and whether) to provide other functions, such as framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or address distribution (e.g., [DAAP]). We describe the new requirements that would be placed on DHCP in the next Section. ITSUMO Group Expires August 2000 [Page 7] Internet Draft Requirements for Extending DHCP March 3, 2000 3. Requirements for Extending DHCP into New Environments Though DHCP has many desirable features, the following requirements created by new environments are not fully met by DHCP: o R1 Rapid client configuration (milliseconds rather than seconds). o R2 Rapid client reconfiguration (independent of lease time). o R3 Efficient use of scarce wireless bandwidth. o R4 Allowing clients to be routers. o R5 Enhanced registration (e.g, user identification and security). o R6 Flexible proxies that can act as both relay or server. o R7 Allowing dynamic server and relay reconfiguration. This section gives a brief description and motivation for each new requirement. 3.1 Rapid configuration Configuration latency is critical to users roaming among wireless networks. A DHCP client accepts an OFFER by returning a REQUEST message to the server (which the server ACKS). The client, however, only configures its new address after checking that no other node on the subnet is using it. The DHCP specification [DHC] says a client SHOULD do ARP checking before an assigned address is used. This "in-line" checking results in long delay (typically 3-15 seconds) before communication can resume after a move; too long for many roaming users. While duplicate detection is desirable, it need not be part of the critical path. One possible alternative, for example, would be to have the server do ARP checking on addresses before they are requested. The goal is to get configuration in milliseconds (bounded mostly by by the speed of the access link) rather than seconds. ITSUMO Group Expires August 2000 [Page 8] Internet Draft Requirements for Extending DHCP March 3, 2000 3.2 Rapid reconfiguration DHCP provides no mechanism for servers to force clients to immediately reconfigure (e.g., when network topology changes) or for clients to detect a need to reconfigure (e.g., when a roaming user moves into a new subnet). Indeed, once configured, DHCP clients go into sleep mode, not listening to DHCP messages until the lease is due for renewal. Clients can use external triggers, such as a layer 2 hand-off indication, to jump DHCP into a new state. These triggers, however, may not always: a) be available, b) be standardized, c) have enough information. The information may be needed for a roaming client to decide if it is in a new subnet or to get the location of a DHCP server (to prevent having to broadcast). The goal is to be able to rapidly reconfigure DHCP clients, at any time, without relying on external triggers. 3.3 Bandwidth Efficiency DHCP message overhead is considerably larger than needed, mainly because DHCP kept the same syntax as BOOTP [BOO1] [BOO2] [BOOD]. This was not a problem in the old paradigm where hosts connect to DHCP servers over high speed LANs; especially since DHCP overhead mainly occurs when a host first boots and DHCP adds nothing to normal packet communication overhead. The overhead is perhaps only a problem for roaming nodes using some wireless access networks. Depending on the size of the IP subnets, roaming users might need to reconfigure as fast as every few seconds. Depending on the speed and error rate of the wireless access networks, reducing DHCP message size could significantly improve bandwidth efficiency. (The error rate can be important since larger messages result in higher probability of loss, that increases latency and bandwidth needs.) The goal is to minimize DHCP message size, by reducing the size of individual DHCP messages and possibly by reducing the total number of messages. ITSUMO Group Expires August 2000 [Page 9] Internet Draft Requirements for Extending DHCP March 3, 2000 3.4 Clients as Routers DHCP specification [DHC] says clients must be hosts and that it "is not intended for use in configuring routers." This was not a problem in the old paradigm, where routers were typically part of a hierarchical network that could be manually configured by a system's administrator. As the size and complexity of networks increase (e.g., with more small devices with low power wireless interfaces), routing functionality becomes desirable in places where manual configuration is not desirable. We are NOT proposing that DHCP be extended to simultaneously configure multiple router interfaces or to distribute address pools; only that DHCP could configure a single router interface over a subnet where there is a DHCP server (or relay). This would require no change in DHCP functionality; only a change in allowable application. The goal is to allow DHCP to configure hosts and routers. 3.5 Enhanced Registration Commercial service providers need a scalable way to identify and authenticate users. In addition they may need other registration information such as: a) the location of the client's AAA server (for inter-domain authentication [DHCZ], b) negotiate service requirements and costs, and c) trigger other services (possibly based on a user profile). Many of these features are now being defined for DHCP, but filling the missing needs would be helpful. We assume that DHCP itself only deals with intra-domain registration; a separate AAA protocol [AAAD] [AAAR] meets the inter-domain requirements. The registration and configuration could be done in separate protocols; however we believe integrating the two functions is desirable. First, it reduces the latency, since it requires only one round trip from the client to the network. Second, it forces users to register before they can be configured. Clearly, devious users could still configure themselves, but now they cannot use DHCP to do this. The goal is to allow DHCP to meet the registration needs of diverse service providers. ITSUMO Group Expires August 2000 [Page 10] Internet Draft Requirements for Extending DHCP March 3, 2000 3.6 DHCP Proxies A DHCP client must either connect to a node acting as a DHCP server or connect to a DHCP relay. When a client first activates or moves into a new domain, DHCP message are best relayed to a central server (such as the Domain Agent in Figure 1); however, when users roaming among subnets within a domain DHCP message may best be handled locally. This would require no change in DHCP functionality; only a change in allowable application. The goal is to allow a subnet proxy to act as both a relay and server, depending on a client's status. 3.7 Dynamically changing server (and relay) parameters In some networks it may be desirable to dynamically change the preconfigured information in DHCP servers (and relay agents). For example, the address-pool may change if a topology change occurs [DAAP]. While DHCP should have nothing to do with updating address-pools, it should be able to handle dynamic changes in this information. If an external application changed the information, DHCP should gracefully handle the change (e.g., it may immediately update all its clients). This would require no change in DHCP protocol; only that DHCP servers and relay agents allow dynamic changes in preconfigured information. The goal is to allow dynamic modification of DHCP server (and relay) configured parameters, such as the address-pool, by an external entity. ITSUMO Group Expires August 2000 [Page 11] Internet Draft Requirements for Extending DHCP March 3, 2000 4 Discussion The purpose of this draft is to stimulate discussion and solicit feedback on enhancing DHCP into new environments. These environments include roaming users who do not need transparent address binding (e.g., a mobile web browser) or commercial service providers whose access network provides framing (e.g., a cable access network). Given the large paradigm shift created by these new environments, it is an open question on how to achieve these changes. At the highest level we could slowly enhance DHCP, while maintaining backwards compatibility. A more radical approach would be the creation of a sister protocol such as DRCP [DRCP]. We have not given specific approaches or mechanisms here, except as examples, because we initially want to focus on the requirements. 5. Acknowledgments The authors acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari, S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and Toshiba America Research Incorporated (T. Kodama). The initial ideas came out of a project on complete network autoconfiguration within a domain [DAAP], funded by the U.S. Army Research Laboratory (ARL) under the Advanced Telecommunications and Information Distribution Research Program (ATIRP) Consortium. 6. References [AAAD] P. Calhoun and A. Rubens, "DIAMETER Base Protocol," Internet draft, Work in Progress, Nov 1998. [AAAR] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote Authentication Dial in User Service (RADIUS)," Request for Comments 2138, Apr 1997. [BOO1] B. Croft & J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985. [BOO2] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993. ITSUMO Group Expires August 2000 [Page 12] Internet Draft Requirements for Extending DHCP March 3, 2000 [BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, Bucknell University, October 1993. [CEL] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet draft, , Work in progress, November 1998. [DAAP] A. McAuley and K. Manousakis, "Self-Configuring Networks." To appear Proc. of 4'th Advanced Telecommunications and Information Distribution Research (ATIRP) Conference, University of Maryland, March 2000. [DHC] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131, Mar 1997. [DHCA] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", , Work in progress, October 1999. [DHCB] B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC load balancing algorithm," , Work in progress, October 1999. [DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS," , Work in progress, June 1999. [DHCL] A. Bennett, B. Volz, A. Westerinen, "DHCP Schema for LDAP," , Work in progress, June 1999. [DHCF] R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil, M. Dooley, A. Kapur, "DHCP Failover Protocol," , , Work in progress, October 1999. [DHCZ] S. Das, A. McAuley, S.Baba, and Y.Shobatake, "Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP," , Work in Progress, March 2000. [DRCP] A. McAuley, S. Das, S.Baba, and Y.Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)," , Work in Progress, October 1999. [HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro- mobility support using HAWAII", , Work in progress, June 1999. ITSUMO Group Expires August 2000 [Page 13] Internet Draft Requirements for Extending DHCP March 3, 2000 [MIP] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [MIP6] D. Johnson and C. Perkins, "Mobility Support in IPv6," , Work in Progress, Oct 1999. [MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," , Work in progress, October 1999. [MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos, "Requirements on Mobile IP from a Cellular Perspective," , Work in progress, June 1999. [MIPD] P. Calhoun and C.E. Perkins, "DIAMETER Mobile IP Extensions," Internet draft, Work in Progress, Nov 1998. [MIPN] P. Calhoun and C.E. Perkins, "Mobile IP Network Access Identifier Extension," Work in progress, October 1999. [MIPS] B. Patil, R. Narayanan & E. Qaddoura, "Security Requirements/ Implementaion Guidelines for Mobile IP using IP security" Internet draft, Work in Progress, June,1999. [MIPT] Tom Hiller, et al. "3G Wireless Data Provider Architecture Using Mobile IP and AAA," , Internet draft, Work in progress, October 1999. [NAI] B. Aboba and M. A. Beadles, "The network access identifier," RFC 2486, January 1999. [PPP] W. Simpson, "The Point to Point Protocol (PPP),: Internet STD 51, July 1994. [PPPE] L. Mamakos, et al., "Method for Transmitting PPP Over Ethernet (PPPoE)," RFC 2516, February 1999. [PPPL] W. Townsley, et al, "Layer Two Tunneling Protocol L2TP," RFC 2661, August 1999. [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC-2119, March 1997. [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, March 1999. ITSUMO Group Expires August 2000 [Page 14] Internet Draft Requirements for Extending DHCP March 3, 2000 [SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using SIP", Proc. of second ACM International Workshop on Wireless Mobile Multimedia (WOWMOM'99), pp 76-82, August, 1999. 7. Authors' Addresses Anthony J. McAuley MCC 1C235B, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4698 email: mcauley@research.telcordia.com Subir Das MCC 1D210R, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com Shinichi Baba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 4759 email: sbaba@tari.toshiba.com Yasuro Shobatake Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 3951 email: yasuro.shobatake@toshiba.co.jp ITSUMO Group Expires August 2000 [Page 15] From owner-dhcp-v4@bucknell.edu Fri Mar 3 15:52:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08910 for ; Fri, 3 Mar 2000 15:52:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA03944; Fri, 3 Mar 2000 15:52:04 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA17061 for ; Fri, 3 Mar 2000 15:51:54 -0500 (EST) Received: from earth.research.telcordia.com (earth [192.4.18.66]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA16496 for ; Fri, 3 Mar 2000 15:51:23 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <38C025C5.A1CDCEB6@earth.research.telcordia.com> Date: Fri, 03 Mar 2000 15:51:23 -0500 From: Tony McAuley Organization: Telcordia X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: new dhcp aaa requirements draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com X-Sender: mcauley@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Please find attached a new draft draft-ietf-dhc-aaa-requirements-00.txt We'd appreciate any comments and suggestions on this draft. Thanks Tony & Subir Network Working Group Subir Das INTERNET-DRAFT Anthony McAuley Internet Engineering Task Force Telcordia Technologies draft-ietf-dhc-aaa-requirements-00.txt Shinichi Baba Date: March 3, 2000 Yasuro Shobatake Expires: August 3, 2000 Toshiba America Research Inc. Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of sections 10 of RFC 2026. 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 The AAA working group is currently defining the requirements for Authentication, Authorization, and Accounting (AAA). This draft lists the AAA requirements to aid roaming nodes using a dynamic address configuration protocol such as DHCP. The node may or may not be using Mobile IP [3] (with co-located care-of-address) or other dynamic address binding protocol. ITSUMO Group Expires August 2000 [Page 1] Internet Draft AAA Requirements using DHCP March 2000 1. Introduction A network providing communication services to nodes from foreign domains, must use Authorization, Authentication, and Accounting (AAA) services [1,2]. A dynamically roaming node places stronger requirements on AAA than a static node. Moreover, next generation network applications will raise the requirements on IP network even higher. The Mobile IP [3] Working Group is currently specifying the requirements for a roaming node using Mobile IP with Foreign Agents [4]. This document specifies the requirements for a roaming node who obtains an address using DHCP [5] [17] or similar node configuration protocol (e.g., DRCP [6]). Recent drafts [7,8] specify how to add authentication to DHCP messages. This allows clients to verify DHCP servers or servers to verify DHCP clients. It does not, however, specify the interaction with a AAA protocol to allow roaming users to access networks in multiple administrative domains. The document is independent of whether the roaming node uses dynamic address binding. The roaming node getting an address through DHCP [5] and once authenticated via AAA [1, 13,14] may also use Mobile IP with co-located addresses, dynamic DNS updates [9,10], or any other dynamic address binding techniques [15,16]. The document does not discuss the pros and cons of how best to support roaming users, only to ensure that the AAA protocol is sufficiently flexible to support both nodes using Mobile IP with Foreign Agents and nodes using DHCP (with or without Mobile IP). Since many of the requirements for DHCP are similar to those for Mobile IP with Foreign Agents, we borrow heavily from the Mobile IP requirements document [3, 4]. 1.1 Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ]. ITSUMO Group Expires August 2000 [Page 2] Internet Draft AAA Requirements using DHCP March 2000 2. Basic Model Figure 2 shows that our general model is very much similar to that described in [4]. The only change is that we do not assume the AAA authentication is necessarily done in a home domain. We assume, more generally, that the roaming node authentication is done in a (possibly distributed) Public AAA (AAAP), which is similar to AAA broker model. The reasons for using the AAAP are discussed in section 4. Each DHCP client might use a different AAAP that can check its credentials, or they may share the same AAAP (even if they are from different domains). Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | | +--------+ | +---+---+ | | DHCP | DHCP | | DHCP | | | Client |-------|--| Server| | +--------+ | +-------+ | AAAP = Public authority | | AAAL = local authority +-------------+ Figure 1: AAA Servers Model DHCP server does not have direct access to the data needed for authentication. So it is expected that the server will consult the local authority (AAAL) for verification. Since the server and the local authority are in the same domain it is assumed that they will have strong security associations. Alternatively, they may be co-located. On the other hand, AAAL itself may not have enough information stored locally to complete the transaction. However, AAAL is expected to be configured with enough information to negotiate the client's verification with corresponding AAAP. Sometimes client may notify its own AAAP for verification via its registration message (e.g., Client's NAI [11]). The local AAA and public AAA should have sufficient security relationships and access control so that they can negotiate the authorization and enable the client to have the requested resources. Once this is over, DHCP ITSUMO Group Expires August 2000 [Page 3] Internet Draft AAA Requirements using DHCP March 2000 server will be notified about the successful negotiation and the server can provide the requested resources to the client. If it is not authorized, server will be informed to terminate the service to the client. 3. Requirements Based on the above scenarios, the following specific requirements for AAA can be ascertained. - Either the DHCP Server and AAAL are co-located or they share a security relationship. - The DHCP server should be configured to obtain authorization from a trusted local AAA server (AAAL). - The local authority (AAAL) has to share, or dynamically establish, security relationships with public authorities (AAAP) that are able to check client credentials. - The client must have a security association with its public authority (AAAP). - Nobody can reconstruct and reuse the credentials that the client uses. - The DHCP server MUST be able to terminate service to the client based on policy determination by the AAA server. - The DHCP server should be able to handle requests for many clients simultaneously. - The client may resend a request if it does not get a reply in some time, so the AAA entities must be designed to operate correctly and efficiently with multiple requests for the same client. - The DHCP server has to keep state for pending client requests while the local authority contacts the appropriate external authority. - Support replay protection and optional non-repudiation capabilities for all authorization and accounting messages. - AAA server need not know any IP address of the client and it identifies clients by other means, e.g., Network Access ITSUMO Group Expires August 2000 [Page 4] Internet Draft AAA Requirements using DHCP March 2000 Identifier (NAI). - Client NAI domain allows AAAL to easily determine the AAAP. - The local AAA server MUST support anonymous access. - There is no requirement for AAA to transport `DHCP or other node configuration messages'. - AAA must complete in one round trip. A major component of the setup latency is the time taken to traverse the wide-area Internet that is likely to separate the AAAL and the AAAP. - AAA must allow a node to register once in its domain and move among subnets in the same domain without requiring more AAA. After the initial registration, the AAAP and AAAL would not be needed. - Support accounting information via AAAP servers providing accounting clearinghouse and reconciliation between serving and home networks. - AAA MUST support message privacy and integrity. 4. Reasons for using Public AAA AAA servers model in [4] shows a configuration in which the local and the home authority have to share trust. This configuration causes a quadratic growth in the number of trust relationships as the number of AAA authorities (local AAA and home AAA) increases. This has been identified as a problem by the roamops working group [12], and any AAA proposal MUST solve this problem. Using public AAA (AAAP) solves many of the scalability problems associated with requiring direct business/roaming relationships between every two administrative domains. A public AAA may play the role of a proxy between two administrative domains which have security associations with the AAAP, and relay AAA messages back and forth securely. The AAAP enables the local and home domains to cooperate without requiring each of the networks to have a direct business or security relationship with all the other networks. Thus, AAAPs offer the needed scalability for managing trust relationships between otherwise independent network domains. Use of the AAAP does not preclude managing separate trust relationships between domains, but it does offer an alternative suitable for commercial environments. ITSUMO Group Expires August 2000 [Page 5] Internet Draft AAA Requirements using DHCP March 2000 5. Security Considerations This draft defines the AAA requirements for roaming nodes using DHCP or similar type of node configuration protocol. Since AAA is security driven, most of this documents addresses the security considerations AAA must make on behalf of roaming nodes using node configuration protocols. 6. Acknowledgements The requirements in section 3 were taken from a draft submitted by S. Glass, S. Jacobs, and C. Perkins of the Mobile IP working group. We would like to acknowledge their work. The authors acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari, S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and Toshiba America Research Incorporated (T. Kodama). References [1] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA Authorizatiopn Requirements," , October 1999. [2] J. Arkko, "Requirements for Internet-scale Accounting Management," , August, 1998. [3] C. Perkins, "IP Mobility Support," RFC 2002, October 1996. [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," , October, 1999. [5] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131, March, 1997. [6] A. McAuley, S. Das, S. Baba, Y. Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)," , October, 1999. ITSUMO Group Expires August 2000 [Page 6] Internet Draft AAA Requirements using DHCP March 2000 [7] R. Droms, "Authentication for DHCP Messages," , October, 1999. [8] V. Gupta, "Flexible Authentication for DHCP Messages," , October, 1998. [9] A. Gustafsson, "A DNS RR for encoding DHCP information," , October, 1999. [10] M. Stapp, Y. Rekhter, "Interaction between DHCP and DNS," , October, 1999. [11] B. Aboba and M. A. Beadles, "The network access identifier," RFC 2486, January 1999. [12] B. Adoba and G. Zorn, "Criteria for evaluating roaming protocols," RFC 2477, December 1998. [13] J. Wang and R. Wang, "Cellular network Authentication, Authorization, and Accounting requirements," , October, 1999. [14] M. Beadles and et.al., "Criteria for evaluating AAA protocols for network access", , October 1999. [15] H. Schulzrinne and et. al., "SIP: Session initiation protocol," RFC 2543, March 1999. [16] E. Wedlund and H. Schulzrinne, "Mobility support using SIP", Proc. The second ACM International workshop on Wireless Mobile Multimedia, ACM/IEEE, pp 76-82, August, 1999. [17] A. McAuley, S. Das, S. Baba, Y. Shobatake, " Requirements for Extending DHCP into New Environments," , March, 2000. 7. Authors' Addresses Subir Das MCC 1D210R, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com ITSUMO Group Expires August 2000 [Page 7] Internet Draft AAA Requirements using DHCP March 2000 Anthony J. McAuley MCC 1C235B, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4698 email: mcauley@research.telcordia.com Shinichi Baba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 4759 email: sbaba@tari.toshiba.com Yasuro Shobatake Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 3951 email: yasuro.shobatake@toshiba.co.jp ITSUMO Group Expires August 2000 [Page 8] From owner-dhcp-v4@bucknell.edu Sun Mar 5 13:59:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10582 for ; Sun, 5 Mar 2000 13:59:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA09571; Sun, 5 Mar 2000 13:59:00 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA32409 for ; Sun, 5 Mar 2000 13:58:42 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 5 Mar 2000 13:58:11 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C9634@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: Bernie Volz , "'dhcp-v4@bucknell.edu'" Subject: Failover comments Date: Sun, 5 Mar 2000 13:58:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, I have an additional (optional) parameter to allow setting a new operational parameter for load balancing. I figure if you decide to put this in, it is easier if you pick the number for it. Proposed text: 6.2.23. Load balancing delayed service option If this option is present, it allows a server that implements load balancing to respond in a delayed manner, instead of ignoring a client. If the option is not present, the client will not be served, unless the hash value yields a "must serve" decision. If the option is present, the server MAY serve the client, if the 'secs' value sent by the client is not zero, or if the server detects multiple requests from the same client. Code Len +-----+--------+------+-----+----+ | 0 | TBD | 0 | 1 | 1 | +-----+--------+------+-----+----+ =============== Another issue: I do appreciate the new 2 byte option code / length format, and the emphasis on being in a different option space than the standard DHCP space. I still think that keeping the type code the same as the existing DHCP option values would have some utility. From the implementation angle, it is a pain in the kazoo to maintain a mapping table between the 2 option spaces. If the values were the same, it would be a simple matter of expanding the one byte value into a 2 byte value for any existing option. The Failover specific options could be placed far up, somewhere in the 30.000 range, to leave room for any imaginable future DHCP options. /sG From owner-dhcp-v4@bucknell.edu Sun Mar 5 21:14:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13617 for ; Sun, 5 Mar 2000 21:14:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA18530; Sun, 5 Mar 2000 21:13:53 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id VAA28853; Sun, 5 Mar 2000 21:13:32 -0500 (EST) Received: from grosse.manhattan.fugue.com (mg131-087.ricochet.net [204.179.131.87]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA24805; Sun, 5 Mar 2000 18:07:08 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id VAA01798; Sat, 26 Feb 2000 21:35:41 -0700 (MST) Message-Id: <200002270435.VAA01798@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: Steve Gonczi , "'kkinnear@cisco.com'" , "'robs@join.com'" , "'volz@alcor.process.com'" , "'droms@bucknell.edu'" , "'grabil@lucent.com'" , "'dhcp-v4@bucknell.edu'" Subject: Re: DHCP Load balancing draft addition In-Reply-To: Message from Bernie Volz of "Fri, 25 Feb 2000 12:54:32 EST." <63D30D6E10CFD11190A90000F805FE860248BD21@lespaul.process.com> Date: Sat, 26 Feb 2000 21:35:40 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The advantage to having the server "store" information is that it is > potentially more accurate. Do we care? When do you need precision here? It seems to me like mostly you need to answer the question "is this a retry?". The language does a good job of providing that capability, and minimizes the likelihood that the implementor of an RFC-conformant *client* will be surprised by the behaviour of a DHCP server. I think this is much more important than the potential for being more accurate, which I am not sure I agree exists anyway. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Mar 6 06:57:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02450 for ; Mon, 6 Mar 2000 06:57:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA28719; Mon, 6 Mar 2000 06:56:51 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA10908 for ; Mon, 6 Mar 2000 06:56:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02296; Mon, 6 Mar 2000 06:56:29 -0500 (EST) Message-Id: <200003061156.GAA02296@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-pv4-reconfigure-00.txt Date: Mon, 06 Mar 2000 06:56:28 -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 : Dynamic host configuration : DHCP reconfigure extension Author(s) : P.De Schrijver, Y. T'Jones, C. Hublet Filename : draft-ietf-dhc-pv4-reconfigure-00.txt Pages : 5 Date : 03-Mar-00 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-00.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-pv4-reconfigure-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000303085734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303085734.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Mar 6 09:37:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07467 for ; Mon, 6 Mar 2000 09:37:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA21461; Mon, 6 Mar 2000 09:37:07 -0500 (EST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA03967 for ; Mon, 6 Mar 2000 09:36:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id JAA07182 for ; Mon, 6 Mar 2000 09:36:32 -0500 (EST) Date: Mon, 6 Mar 2000 09:36:32 -0500 (EST) From: "William A. Arbaugh" To: DHCPv4 discussion list Subject: Reminder to provide authentication draft comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN We want to have the final call on this draft so please provide any comments/edits soon! Thanks, Bill ----------------------------------------------------------------------- Bill Arbaugh email: waa@dsl.cis.upenn.edu web: http://www.cis.upenn.edu/~waa ----------------------------------------------------------------------- From owner-dhcp-v4@bucknell.edu Mon Mar 6 10:18:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09100 for ; Mon, 6 Mar 2000 10:18:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA25180; Mon, 6 Mar 2000 10:18:42 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA03141 for ; Mon, 6 Mar 2000 10:18:38 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 10:18:07 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C9637@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Subject: Re: Date: Mon, 6 Mar 2000 10:18:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, Category 1) of this draft seems to be a bit strictly defined. IMO there is no new option that could possible fit into it. We may as well do away with it. Think about it: How can you possibly introduce something NEW, if : " Options in this category MUST NOT require changes to the DHCP protocol, server, client, or BOOTP relay agent implementations." /sG From owner-dhcp-v4@bucknell.edu Mon Mar 6 11:40:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13787 for ; Mon, 6 Mar 2000 11:40:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA14558; Mon, 6 Mar 2000 11:40:12 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA29705 for ; Mon, 6 Mar 2000 11:39:54 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23806; Mon, 6 Mar 2000 09:39:51 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA23422; Mon, 6 Mar 2000 08:39:24 -0800 (PST) Received: from jurassic.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e26Gd9L07459; Mon, 6 Mar 2000 08:39:11 -0800 (PST) From: Mike Carney Message-Id: <200003061639.e26Gd9L07459@jurassic.eng.sun.com> Date: Mon, 6 Mar 2000 08:38:37 -0800 To: DHCPv4 discussion list Cc: Subject: Re: X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Reply-To: Michael.Carney@eng.sun.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Hello, Hi Steve, > >Category 1) of this draft seems to be a bit strictly defined. > IMO there is no new option that could possible fit into it. We may as well >do away with it. > >Think about it: >How can you possibly introduce something NEW, if : > > " Options in this category MUST NOT require changes to the DHCP > protocol, server, client, or BOOTP relay agent implementations." Most (if not all) DHCP servers have an ability to be configured to deal with new options without requiring changes to the server code or the management tools. Options that don't fall into category 1 would be dependent on other options, change the protocol in some way, or are formatted in such a way that current implementations would need to change. Most (if not all) DHCP clients provide a mechanism for applications to use to query them for DHCP option data. As long as the option has no impact on the protocol itself, no change to the client implementation is needed. Currently, relay agents don't do anything with the options block. Any option that would require changes to relay agents such as they do require change certainly wouldn't be a category 1 candidate. I think most options tend to fall in category one - Lists of IP addresses, ASCII strings, Numbers of various sizes. Why would options such as these require changes of implementations? > >/sG > Mike From owner-dhcp-v4@bucknell.edu Mon Mar 6 11:55:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14474 for ; Mon, 6 Mar 2000 11:55:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA13439; Mon, 6 Mar 2000 11:55:14 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA26858 for ; Mon, 6 Mar 2000 11:55:07 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 11:54:32 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C9638@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: Date: Mon, 6 Mar 2000 11:54:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I guess I should be more careful in using sarcasm to get a point accross... What I was trying to say: The important criteria should be: "The new option should MUST NOT break existing client / server /relay implementations. It is OK to change a server or client to take advantage of the new option, as long as all existing protocol participants continue working as before." sG From owner-dhcp-v4@bucknell.edu Mon Mar 6 13:03:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17780 for ; Mon, 6 Mar 2000 13:03:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA25473; Mon, 6 Mar 2000 13:02:59 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA14140 for ; Mon, 6 Mar 2000 13:02:47 -0500 (EST) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Mon, 6 Mar 2000 11:16:33 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GHMWWZ0W; Mon, 6 Mar 2000 11:16:27 -0500 Received: from netgww (NET-GWW [141.251.80.117]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FHAFJV8N; Mon, 6 Mar 2000 11:16:27 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Glenn Waters" To: DHCPv4 discussion list Cc: Gonczi Subject: RE: Date: Mon, 6 Mar 2000 11:14:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <63D30D6E10CFD11190A90000F805FE86023C9637@lespaul.process.com> Reply-To: gww@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit We may be arguing about semantics however, our server is data driven and new options do not require any modification of the code for the new options to work. I would not consider a new option that can be data driven to be changing the protocol. The only piece left is the client. I would suspect clients would have to change to make use of the new option, however they probably can just "pick up" the new option data without having to change client DHCP code. Just my 2 cents worth. /gww -----Original Message----- From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On Behalf Of Steve Gonczi Sent: Monday, March 6, 2000 10:18 To: DHCPv4 discussion list Subject: Re: Hello, Category 1) of this draft seems to be a bit strictly defined. IMO there is no new option that could possible fit into it. We may as well do away with it. Think about it: How can you possibly introduce something NEW, if : " Options in this category MUST NOT require changes to the DHCP protocol, server, client, or BOOTP relay agent implementations." /sG From owner-dhcp-v4@bucknell.edu Mon Mar 6 13:15:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18093 for ; Mon, 6 Mar 2000 13:15:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA09813; Mon, 6 Mar 2000 13:15:27 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA14784 for ; Mon, 6 Mar 2000 13:15:11 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id KAA01179 for ; Mon, 6 Mar 2000 10:14:12 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id KAA06988 for ; Mon, 6 Mar 2000 10:15:05 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 10:14:39 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75ABE@msgsrv04.srv.pacbell.com> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: Date: Mon, 6 Mar 2000 10:14:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > We may be arguing about semantics however, our server is data driven and > new > options do not require any modification of the code for the new options to > work. I would not consider a new option that can be data driven to be > changing the protocol. The only piece left is the client. I would > suspect > clients would have to change to make use of the new option, however they > probably can just "pick up" the new option data without having to change > client DHCP code. > > ...true.... since I have only one customer, my perspective on changes to the servers is a bit biased, but if I can either (1) use the existing configuration elements to support a new option, or (2) extend the functionality incrementally, I don't consider a new option to be in violation of the principle. Because of our client population size, there have been several occasions where the server support for an option was available months before any client could request it. With apologies, this is sort of like the debate on pornography: "I can't define it, but I know it when I see it!" --Barr From owner-dhcp-v4@bucknell.edu Fri Mar 10 02:39:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18324 for ; Fri, 10 Mar 2000 02:38:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA18569; Fri, 10 Mar 2000 02:37:51 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id CAA11221 for ; Fri, 10 Mar 2000 02:37:09 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id XAA75297; Thu, 9 Mar 2000 23:25:18 -0800 (PST) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: new dhcp aaa requirements draft Date: Thu, 9 Mar 2000 23:36:07 -0800 Message-ID: <021101bf8a63$4dc980f0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38C025C5.A1CDCEB6@earth.research.telcordia.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Some comments on this draft: 1. Much as was the case with Mobile IP registration, the default authentication methods specified in the DHCP authentication draft are not very compatible with AAA in that they require not only verification of the DHCP authentication option, but also *generation* of the option on behalf of the DHCP server. The latter is not something that most AAA servers are prepared to do. So trying to interface the DHCP authentication draft to AAA seems a tenuous proposition at best. 2. If one uses either of the other DHCP authentication drafts (public key or Kerberos) then conventional AAA is not necessary since these methods allow evaluation of the client credentials by the DHCP server without AAA remoting. Since DHCP servers have their own configuration, it would seem that AAA authorization is irrelevant as well. 3. This draft begs the question as to whether the DHC WG cares about inter-realm DHCP authentication or not. If not, then roaming compatibility is not a goal either. The DHCP authentication draft claims this is out of scope, yet it is addressed by the other two drafts. From owner-dhcp-v4@bucknell.edu Fri Mar 10 05:25:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08686 for ; Fri, 10 Mar 2000 05:25:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA27540; Fri, 10 Mar 2000 05:25:19 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA01910; Fri, 10 Mar 2000 05:25:12 -0500 (EST) From: pratikg@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA14736; Fri, 10 Mar 2000 05:07:27 -0600 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id FAA58924; Fri, 10 Mar 2000 05:25:11 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525689E.00393A20 ; Fri, 10 Mar 2000 05:25:04 -0500 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list cc: droms@bucknell.edu, dhcp-v4@bucknell.edu Message-ID: <8525689E.00393831.00@d54mta04.raleigh.ibm.com> Date: Fri, 10 Mar 2000 05:24:56 -0500 Subject: Please publish ID draft-ietf-dhc-domsrch-03.txt Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=PNbOnlxTxd9YuDBPghQCiG3rQevnsf5wHYDmD2gT9foe1KF80hKmQltv" Content-Disposition: inline Reply-To: pratikg@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=PNbOnlxTxd9YuDBPghQCiG3rQevnsf5wHYDmD2gT9foe1KF80hKmQltv Content-type: text/plain; charset=us-ascii Content-Disposition: inline This is a product of the DHC WG. (See attached file: draft-ietf-dhc-domsrch-03.txt) Pratik Gupta pratikg@us.ibm.com --0__=PNbOnlxTxd9YuDBPghQCiG3rQevnsf5wHYDmD2gT9foe1KF80hKmQltv Content-type: application/octet-stream; name="draft-ietf-dhc-domsrch-03.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-domsrch-03.txt" Content-Description: Text - character set unknown Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFAuIEd1cHRhDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJQk0gQ29ycG9yYXRpb24NCk9ic29sZXRlczog ZHJhZnQtaWV0Zi1kaGMtZG9tc3JjaC0wMi50eHQgICAgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAwMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAyMDAwDQoNCg0KICAgICAgICAgICAgICAgICAgIFRoZSBEb21haW4g U2VhcmNoIE9wdGlvbiBmb3IgREhDUA0KICAgICAgICAgICAgICAgICAgICA8ZHJhZnQtaWV0Zi1k aGMtZG9tc3JjaC0wMy50eHQ+DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdC4gIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZw0K ICAgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRG KSwgaXRzIGFyZWFzDQogICBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl DQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcyIuDQoNCiAgIFRvIHZpZXcgdGhlIGVudGlyZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzLCBwbGVhc2UgY2hlY2sgdGhlDQogICAiMWlkLWFic3RyYWN0cy50eHQiIGxpc3Rpbmcg Y29udGFpbmVkIGluIHRoZSBJbnRlcm5ldC1EcmFmdHMgU2hhZG93DQogICBEaXJlY3RvcmllcyBv biBmdHAuaXMuY28uemEgKEFmcmljYSksIGZ0cC5ub3JkdS5uZXQgKE5vcnRoZXJuDQogICBFdXJv cGUpLCBmdHAubmljLml0IChTb3V0aGVybiBFdXJvcGUpLCBtdW5uYXJpLm96LmF1IChQYWNpZmlj IFJpbSksDQogICBmdHAuaWV0Zi5vcmcgKFVTIEVhc3QgQ29hc3QpLCBvciBmdHAuaXNpLmVkdSAo VVMgV2VzdCBDb2FzdCkuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IG5ldyBESENQIG9wdGlvbiB3aGljaCBpcyBwYXNzZWQgZm9ybSB0aGUgREhDUA0KICAgU2VydmVy IHRvIHRoZSBESENQIENsaWVudCB0byBjb25maWd1cmUgdGhlIGRvbWFpbiBzZWFyY2ggbGlzdCB3 aGljaA0KICAgaXMgdXNlZCBieSB0aGUgY2xpZW50cyB0byByZXNvbHZlIGhvc3RuYW1lcyBpbiB0 aGUgRG9tYWluIE5hbWUNCiAgIFN5c3RlbVszXS4NCg0KDQpJbnRyb2R1Y3Rpb24NCg0KICAgVGhl IER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKVsxXSBwcm92aWRlcyBh DQogICBmcmFtZXdvcmsgZm9yIHBhc3NpbmcgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiB0byBo b3N0cyBvbiBhIFRDUC9JUA0KICAgbmV0d29yay4gUkZDIDIxMzIgYWxsb3dzIHRoZSBEb21haW4g TmFtZSAob3B0aW9uIDE1KSBhbmQgdGhlIERvbWFpbg0KICAgTmFtZSBTZXJ2ZXIgKG9wdGlvbiA2 KSB0byBiZSBwYXNzZWQgdG8gdGhlIERIQ1AgY2xpZW50LiBUaGlzDQogICBpbmZvcm1hdGlvbiBp cyB1c2VkIHRvIHJlc29sdmUgbmFtZXMgaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbS4gVGhlc2UN CiAgIG9wdGlvbnMgYXJlIHVzdWFsbHkgcGxhY2VkIGluIHRoZSByZXNvbHYuY29uZiBmaWxlIG9u IG1vc3Qgb3BlcmF0aW5nDQogICBzeXN0ZW1zLiBUaGUgbmFtZSByZXNvbHV0aW9uIHJvdXRpbmVz IG9uIHRoZSBjbGllbnQgYXJlIGFsc28gY2FwYWJsZQ0KICAgb2YgdXNpbmcgYSBkb21haW4gc2Vh cmNoIGxpc3QgdGhhdCBhbGxvd3MgbmFtZSByZXNvbHV0aW9uIHRvIGJlDQogICBhdHRlbXB0ZWQg aW4gYSBudW1iZXIgb2YgZG9tYWlucyBpbiBzZXF1ZW5jZS4gVGhlIERvbWFpbiBTZWFyY2gNCiAg IE9wdGlvbiBhbGxvd3MgYSBsaXN0IG9mIGRvbWFpbiBuYW1lcywgaW4gb3JkZXIgb2YgcHJlZmVy ZW5jZSwgdG8gYmUNCiAgIHBhc3NlZCB0byB0aGUgREhDUCBjbGllbnQgc3VjaCB0aGF0IHRoZSBz ZWFyY2ggZGlyZWN0aXZlIGNhbiBiZQ0KDQoNCg0KR3VwdGEgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoNCg0KDQoNCg0K SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDAwDQoNCg0KICAgc3BlY2lmaWVkIGZvciBuYW1lIHJlc29sdXRpb24uDQoN Cg0KRGVmaW5pdGlvbnMNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbNF0uDQoN CiAgIFRoaXMgZG9jdW1lbnQgYWxzbyB1c2VzIHRoZSBmb2xsb3dpbmcgdGVybXM6DQoNCiAgICAg ICJESENQIGNsaWVudCINCg0KICAgICAgICAgICBESENQIGNsaWVudCBvciAiY2xpZW50IiBpcyBh biBJbnRlcm5ldCBob3N0IHVzaW5nIERIQ1AgdG8NCiAgICAgICAgICAgb2J0YWluIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycyBzdWNoIGFzIGEgbmV0d29yayBhZGRyZXNzLg0KDQogICAgICAiREhD UCBzZXJ2ZXIiDQoNCiAgICAgICAgICAgQSBESENQIHNlcnZlciBvciAic2VydmVyIiBpcyBhbiBJ bnRlcm5ldCBob3N0IHRoYXQgcmV0dXJucw0KICAgICAgICAgICBjb25maWd1cmF0aW9uIHBhcmFt ZXRlcnMgdG8gREhDUCBjbGllbnRzLg0KDQpEb21haW4gU2VhcmNoIE9wdGlvbiBGb3JtYXQNCg0K ICAgVGhlIGNvZGUgZm9yIHRoaXMgb3B0aW9uIGlzIFRCRCwgYW5kIGl0cyBtaW5pbXVtIGxlbmd0 aCBpcyAyIGJ5dGVzLg0KDQogICAgICAgICAgICAgQ29kZSAgICAgTGVuICAgICAgIERvbWFpbiBO YW1lcyBpbiBTZXF1ZW5jZQ0KICAgICAgICAgICArLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0t LS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLQ0KICAgICAgICAgICB8ICBUQkQgIHwgICBuICAg fCAgbmQxICB8ICAgZDEgICB8ICAgbmQyICAgfCAgICBkMiAgIHwNCiAgICAgICAgICAgKy0tLS0t LS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0NCg0KICAg V2hlcmUgZDEgJiBkMiBhcmUgZG9tYWluIG5hbWVzIGFuZCBuZDEgYW5kIG5kMiBhcmUgdGhlIGxl bmd0aHMgb2YgdGhlDQogICBkb21haW4gbmFtZXMgcmVzcGVjdGl2ZWx5LiAgQW55IG51bWJlciBv ZiBkb21haW4gbmFtZXMgY2FuIGJlDQogICBzcGVjaWZpZWQgKHdpdGhpbiB0aGUgc2l6ZSBsaW1p dGF0aW9ucyBvZiB0aGUgREhDUCBvcHRpb25zIHNwYWNlIGFzDQogICBzcGVjaWZpZWQgaW4gUkZD MjEzMi4gVGhpcyBvcHRpb24gYWxsb3dzIGEgcmljaGVyIGNoYXJhY3RlciBzZXQgdG8gYmUNCiAg IHVzZWQgZm9yIHNwZWNpZnlpbmcgdGhlIEROUyBkb21haW4gbmFtZSB0aGFuIGlzIGN1cnJlbnRs eSBzdXBwb3J0ZWQNCiAgIGJ5IGRlcGxveWVkIEROUyBzZXJ2ZXJzLiBUaGlzIGFsbG93cyBwb3Nz aWJsZSBldm9sdXRpb24gb2YgdGhlIEROUw0KICAgbmFtZXNwYWNlIGluIHRoZSBmdXR1cmUgd2l0 aG91dCBhZmZlY3RpbmcgdGhpcyBvcHRpb24uDQoNCg0KREhDUCBDbGllbnQgQmVoYXZpb3INCg0K ICAgVGhlIERIQ1AgY2xpZW50IHdpbGwgdXNlIHRoaXMgb3B0aW9uIHRvIGNyZWF0ZSBhIGRvbWFp biBzZWFyY2ggbGlzdA0KICAgZm9yIG5hbWUgcmVzb2x1dGlvbi4gSWYgYSBESENQIGNsaWVudCBp cyBnaXZlbiBib3RoIGEgRG9tYWluIE5hbWUNCiAgIE9wdGlvbiBhbmQgYSBEb21haW4gU2VhcmNo IE9wdGlvbiwgdGhlIHJlc3BlY3RpdmUgZG5zIGNsaWVudCBwb2xpY2llcw0KICAgd2lsbCBkZXRl cm1pbmUgdGhlIGJlaGF2aW9yLg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQoNCg0KDQpH dXB0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMl0NCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDANCg0KDQogICBESENQIGN1 cnJlbnRseSBwcm92aWRlcyBubyBhdXRoZW50aWNhdGlvbiBvciBzZWN1cml0eSBtZWNoYW5pc21z Lg0KICAgUG90ZW50aWFsIGV4cG9zdXJlcyB0byBhdHRhY2sgYXJlIGRpc2N1c3NlZCBpbiBzZWN0 aW9uIDcgb2YgdGhlIERIQ1ANCiAgIHByb3RvY29sIHNwZWNpZmljYXRpb24gWzFdLiBUaGUgRG9t YWluIFNlYXJjaCBPcHRpb24gY2FuIGJlIHVzZWQgdG8NCiAgIG1pc2RpcmVjdCBkb21haW4gbmFt ZSByZXNvbHV0aW9uIG9uIGEgY2xpZW50IGFuZCB0aHVzIG1pc2RpcmVjdA0KICAgbmV0d29yayB0 cmFmZmljIGJhc2VkIG9uIEROUyBuYW1lcy4NCg0KDQpSZWZlcmVuY2VzDQoNCiAgIFsxXSBEcm9t cywgUi4sICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCIsIFJGQyAyMTMxLCBN YXJjaA0KICAgICAgICAxOTk3Lg0KICAgWzJdIEFsZXhhbmRlciwgUy4gYW5kIERyb21zLCBSLiwg IkRIQ1AgT3B0aW9ucyBhbmQgQk9PVFAgVmVuZG9yDQogICAgICAgIEV4dGVuc2lvbnMiLCBSRkMg MjEzMiwgTWFyY2ggMTk5Ny4NCiAgIFszXSBNb2NrYXBldHJpcywgUC4gVi4sICJEb21haW4gbmFt ZXMgLSBpbXBsZW1lbnRhdGlvbiBhbmQNCiAgICAgICAgc3BlY2lmaWNhdGlvbiIsIFJGQyAxMDM1 LCBOb3ZlbWJlciAxOTg3Lg0KICAgWzRdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBpbmRpY2F0ZQ0KICAgICAgICByZXF1aXJlbWVudGxldmVscyIsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQoNCkF1dGhvciBJbmZvcm1hdGlvbg0KDQpQcmF0aWsgR3VwdGENCklC TSBDb3Jwb3JhdGlvbg0KNDIwNSBTLk1pYW1pIEJsdmQNClJlc2VhcmNoIFRyaWFuZ2xlIFBhcmss IE5DIDI3NzA5DQpQaG9uZTogKDkxOSkyNTQtNTY1NA0KZW1haWw6IHByYXRpa2dAdXMuaWJtLmNv bQ0KDQoNCkV4cGlyYXRpb24NCg0KDQpUaGlzIGRvY3VtZW50IHdpbGwgZXhwaXJlIG9uIFNlcHRl bWJlciAzMCwgMjAwMC4NCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMTk5OCkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0K DQpUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQg ZnVybmlzaGVkIHRvDQpvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBv biBvciBvdGhlcndpc2UgZXhwbGFpbiBpdCBvcg0KYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlv biBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIGFuZA0KZGlzdHJpYnV0ZWQsIGlu IHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsDQpwcm92 aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBh cmUgaW5jbHVkZWQNCm9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIEhv d2V2ZXIsIHRoaXMgZG9jdW1lbnQgaXRzZWxmDQptYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3 YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcgdGhlIGNvcHlyaWdodCBub3RpY2UNCm9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9u cywNCmV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50ZXJu ZXQgc3RhbmRhcmRzIGluDQoNCg0KDQpHdXB0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCg0KDQoNCg0KDQpJbnRlcm5l dCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMDANCg0KDQp3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRl ZmluZWQgaW4gdGhlIEludGVybmV0DQpTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2Vk LCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50bw0KbGFuZ3VhZ2VzIG90aGVyIHRo YW4gRW5nbGlzaC4NCg0KDQpUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFy ZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQpyZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2Np ZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuDQoNClRoaXMgZG9jdW1lbnQgYW5kIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuICJBUw0KSVMi IGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HDQoNClRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElN UExJRUQsIElOQ0xVRElORyBCVVQNCk5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRI RSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMDQpOT1QgSU5GUklOR0UgQU5ZIFJJ R0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUg0KRklU TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHdXB0YSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCg0KDQo= --0__=PNbOnlxTxd9YuDBPghQCiG3rQevnsf5wHYDmD2gT9foe1KF80hKmQltv-- From owner-dhcp-v4@bucknell.edu Fri Mar 10 06:48:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05993 for ; Fri, 10 Mar 2000 06:48:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA32279; Fri, 10 Mar 2000 06:48:47 -0500 (EST) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA07132 for ; Fri, 10 Mar 2000 06:48:34 -0500 (EST) Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 10 Mar 2000 11:47:39 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Fri, 10 Mar 2000 11:48:47 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2040873D7@mbtlipnt02.btlabs.bt.co.uk> From: "Privat,J,Jerome,NZD3 PRIVATJ R" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Fri, 10 Mar 2000 11:48:44 -0000 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for your comments. I agree with having 2-bytes fields for N and Ln. I will change it in the next version of the draft. I have no problem with adding a start and end time subfield for each user class value. But I would like to know if other people implementing this option think is a good idea? Can people implementing the User Class option (Ted and others) say if they agree on the list? If we have consensus, I will make the addition in the next version of the draft. Thanks, Jerome -----Original Message----- From: Steve Gonczi [mailto:Gonczi@PROCESS.COM] Sent: 03 March 2000 19:51 To: DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-userclass-05.txt Hello, I believe the N and Ln fields should be 2 byte fields. It is quite possible, that the individual class values end up longer than 255 esp. if the values are generated by some ticket issuing authority / self-registration server. (In practice, these class values may end up being certificates, or some simpler authenticated tickets). Also, it would be quite useful to include start and end time subfields for each class value. (Something like time_t formatted UTC values... 32 bit NBO etc.. etc..) The obvious use of the end time is to provide a ttl for the ticket (a.k.a class x ) and the start time could be used for reserving resources for a specific time slot. E.g.: to schedule a video conference ahead of time. /Steve Gonczi Process Software Corporation From owner-dhcp-v4@bucknell.edu Fri Mar 10 14:55:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22735 for ; Fri, 10 Mar 2000 14:55:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA10998; Fri, 10 Mar 2000 14:55:16 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA05525; Fri, 10 Mar 2000 14:55:03 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA29350; Fri, 10 Mar 2000 14:55:03 -0500 (EST) Message-Id: <4.2.2.20000310145315.00a61d90@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Mar 2000 14:54:25 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG meeting in Adelaide Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN As is our custom, the DHC WG will meet twice at the upcoming IETF meeting in Adelaide - one session for DHCPv4 issues and one for DHCPv6 issues. Tentatively, the DHCPv4 session will occur on Tuesday, 3/28 and the DHCPv6 session on Wednesday, 3/29. If you would like to be included on the agenda for either session, please send me a note describing your agenda item and an estimate of the amount of time you'll neeed. Please get your agenda requests to me by 3/15 (deadline extended!). Note that the cut-off for I-D submission is *today*! The following items are on the agenda for the DHCPv4 session: Use of DHCP for configuration of IPSEC tunnel mode draft-ietf-ipsec-dhcp-04.txt Bernard Aboba Use of DHCP for configuring multicast DNS behavior draft-aboba-dhc-mdns-conf-00.txt Bernard Aboba draft-ietf-dhc-nextserver-01.txt Mike Borella 10 minutes DHCP authentication draft-ietf-dhc-authentication-??.txt Ralph Droms 10 minutes Domain search option draft-ietf-dhc-domsrch-02.txt Ralph Droms (for Pratik Gupta) 10 minutes DHCP Option for PacketCable VoIP Client Configuration" draft-beser-dhc-packetcable-00.txt Burcak Beser 15 minutes From owner-dhcp-v6@bucknell.edu Fri Mar 10 15:01:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24697 for ; Fri, 10 Mar 2000 15:01:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA12135; Fri, 10 Mar 2000 14:55:11 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA05525; Fri, 10 Mar 2000 14:55:03 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA29350; Fri, 10 Mar 2000 14:55:03 -0500 (EST) Message-Id: <4.2.2.20000310145315.00a61d90@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Mar 2000 14:54:25 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: WG meeting in Adelaide 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 As is our custom, the DHC WG will meet twice at the upcoming IETF meeting in Adelaide - one session for DHCPv4 issues and one for DHCPv6 issues. Tentatively, the DHCPv4 session will occur on Tuesday, 3/28 and the DHCPv6 session on Wednesday, 3/29. If you would like to be included on the agenda for either session, please send me a note describing your agenda item and an estimate of the amount of time you'll neeed. Please get your agenda requests to me by 3/15 (deadline extended!). Note that the cut-off for I-D submission is *today*! The following items are on the agenda for the DHCPv4 session: Use of DHCP for configuration of IPSEC tunnel mode draft-ietf-ipsec-dhcp-04.txt Bernard Aboba Use of DHCP for configuring multicast DNS behavior draft-aboba-dhc-mdns-conf-00.txt Bernard Aboba draft-ietf-dhc-nextserver-01.txt Mike Borella 10 minutes DHCP authentication draft-ietf-dhc-authentication-??.txt Ralph Droms 10 minutes Domain search option draft-ietf-dhc-domsrch-02.txt Ralph Droms (for Pratik Gupta) 10 minutes DHCP Option for PacketCable VoIP Client Configuration" draft-beser-dhc-packetcable-00.txt Burcak Beser 15 minutes From owner-dhcp-v4@bucknell.edu Fri Mar 10 15:44:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09988 for ; Fri, 10 Mar 2000 15:44:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA27115; Fri, 10 Mar 2000 15:44:41 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA01836; Fri, 10 Mar 2000 15:44:36 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id MAA19719; Fri, 10 Mar 2000 12:38:26 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA01230; Fri, 10 Mar 2000 12:44:29 -0800 (PST) Message-Id: <200003102044.MAA01230@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: WG meeting in Adelaide In-Reply-To: Message from Ralph Droms of "Fri, 10 Mar 2000 14:54:25 EST." <4.2.2.20000310145315.00a61d90@mail.bucknell.edu> Date: Fri, 10 Mar 2000 12:44:29 -0800 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'd like to try to get the Classless Static Routes option to last call this time, so that should be an agenda item. I'd also like to see some discussion of the latest DHC-DNS draft, although without Mark there it's going to be tough. Thanks! _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Mar 10 17:21:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14165 for ; Fri, 10 Mar 2000 17:21:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA07058; Fri, 10 Mar 2000 17:21:09 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA04763 for ; Fri, 10 Mar 2000 17:21:02 -0500 (EST) Received: from earth.research.telcordia.com (earth [192.4.18.66]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA13373 for ; Fri, 10 Mar 2000 17:20:09 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <38C97517.1B276BC3@earth.research.telcordia.com> Date: Fri, 10 Mar 2000 17:20:08 -0500 From: Tony McAuley Organization: Telcordia X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: RE: new dhcp aaa requirements draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com X-Sender: mcauley@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Appreciate your comments. I agree that the main point is whether DHC-wg should care about inter-realm configuration. If DHC-wg does not think we should care, then I agree that AAA requirements go away. Hopefully, however, we can convince DHC-wg that it should care (see draft-ietf-dhc-enhance-requirements-00.txt); in which case DHCP needs not only authentication, but also authorization (to use resources) and accounting (i.e., to interact with AAA). Hope this clears things a little? Thanks Tony ************************************************************************* > From: "Bernard Aboba" > To: DHCPv4 discussion list > Subject: RE: new dhcp aaa requirements draft > Date: Thu, 9 Mar 2000 23:36:07 -0800 > > Some comments on this draft: > > 1. Much as was the case with Mobile IP registration, > the default authentication methods specified in the > DHCP authentication draft are not very compatible with > AAA in that they require not only verification of the > DHCP authentication option, but also *generation* of > the option on behalf of the DHCP server. The latter > is not something that most AAA servers are prepared > to do. So trying to interface the DHCP authentication > draft to AAA seems a tenuous proposition at best. > > 2. If one uses either of the other DHCP authentication > drafts (public key or Kerberos) then conventional AAA > is not necessary since these methods allow evaluation > of the client credentials by the DHCP server without > AAA remoting. Since DHCP servers have their own configuration, > it would seem that AAA authorization is irrelevant as > well. > > 3. This draft begs the question as to whether the DHC > WG cares about inter-realm DHCP authentication or not. > If not, then roaming compatibility is not a goal either. > The DHCP authentication draft claims this is out of > scope, yet it is addressed by the other two drafts. From owner-dhcp-v4@bucknell.edu Mon Mar 13 06:17:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14510 for ; Mon, 13 Mar 2000 06:17:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA19901; Mon, 13 Mar 2000 06:17:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA22418 for ; Mon, 13 Mar 2000 06:16:40 -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 GAA14076; Mon, 13 Mar 2000 06:16:37 -0500 (EST) Message-Id: <200003131116.GAA14076@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-aaa-requirements-00.txt Date: Mon, 13 Mar 2000 06:16:36 -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 : Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP Author(s) : S. Das, A. McAuley, S. Baba, Y. Shobatake Filename : draft-ietf-dhc-aaa-requirements-00.txt Pages : 8 Date : 10-Mar-00 The AAA working group is currently defining the requirements for Authentication, Authorization, and Accounting (AAA). This draft lists the AAA requirements to aid roaming nodes using a dynamic address configuration protocol such as DHCP. The node may or may not be using Mobile IP [3] (with co-located care-of-address) or other dynamic address binding protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-aaa-requirements-00.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-aaa-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-aaa-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310134426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-aaa-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-aaa-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310134426.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Mar 13 06:22:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16406 for ; Mon, 13 Mar 2000 06:22:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA29096; Mon, 13 Mar 2000 06:22:05 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA14434 for ; Mon, 13 Mar 2000 06:16:44 -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 GAA14130; Mon, 13 Mar 2000 06:16:42 -0500 (EST) Message-Id: <200003131116.GAA14130@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-schema-02.txt Date: Mon, 13 Mar 2000 06:16:41 -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 Schema for LDAP Author(s) : A. Bennett, B. Volz Filename : draft-ietf-dhc-schema-02.txt Pages : 23 Date : 10-Mar-00 This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-schema-02.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-schema-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-schema-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310134436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-schema-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-schema-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310134436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Mar 13 06:23:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16923 for ; Mon, 13 Mar 2000 06:23:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA17134; Mon, 13 Mar 2000 06:23:19 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA06802 for ; Mon, 13 Mar 2000 06:16:49 -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 GAA14142; Mon, 13 Mar 2000 06:16:46 -0500 (EST) Message-Id: <200003131116.GAA14142@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-enhance-requirements-00.txt Date: Mon, 13 Mar 2000 06:16:46 -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 : Requirements for Extending DHCP into New Environments Author(s) : A. McAuley, S. Das, S. Baba, Y. Shobatake Filename : draft-ietf-dhc-enhance-requirements-00.txt Pages : 15 Date : 10-Mar-00 The Dynamic Host Configuration Protocol (DHCP) provides a widely deployed framework for host registration and configuration [DHC]. DHCP, however, was designed only for fixed hosts on physically secure LANs. Other protocols fill some of the gap. PPP [PPP] is a good solution for many commercial service providers (where framing is needed). Mobile IP [MIP] is ideal for registering and configuring roaming users (when transparent address binding is needed). This still leaves many environments where there is no ideal solution, such as: roaming users who do not need transparent address binding e.g., a mobile web browser), and commercial service providers who want to support home networking with multiple nodes. This draft proposes DHCP as the best protocol to meet these new needs, because it leave open how (and whether) to provide other functions, such as framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or address distribution (e.g., [DAAP]). We describe and solicit feedback on seven new requirements that would be placed on DHCP to meet these needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-enhance-requirements-00.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-enhance-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-enhance-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310134447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-enhance-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-enhance-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310134447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Mar 14 06:17:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18651 for ; Tue, 14 Mar 2000 06:17:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA26320; Tue, 14 Mar 2000 06:17:18 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA12744 for ; Tue, 14 Mar 2000 06:16:57 -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 GAA18300; Tue, 14 Mar 2000 06:16:54 -0500 (EST) Message-Id: <200003141116.GAA18300@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-00.txt Date: Tue, 14 Mar 2000 06:16:53 -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-00.txt Pages : Date : 13-Mar-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-00.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-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-packetcable-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135252.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Mar 15 06:23:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28761 for ; Wed, 15 Mar 2000 06:23:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA21114; Wed, 15 Mar 2000 06:22:22 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA26833 for ; Wed, 15 Mar 2000 06:21:44 -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 GAA28045; Wed, 15 Mar 2000 06:21:41 -0500 (EST) Message-Id: <200003151121.GAA28045@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-ipv4-autoconfig-05.txt Date: Wed, 15 Mar 2000 06:21:41 -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 : Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network Author(s) : R. Troll Filename : draft-ietf-dhc-ipv4-autoconfig-05.txt Pages : 8 Date : 14-Mar-00 With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet. This draft describes a method by which a host may automatically give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.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-ipv4-autoconfig-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ipv4-autoconfig-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314132349.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Mar 15 06:26:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00009 for ; Wed, 15 Mar 2000 06:26:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA24619; Wed, 15 Mar 2000 06:26:08 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA24818 for ; Wed, 15 Mar 2000 06:21:49 -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 GAA28077; Wed, 15 Mar 2000 06:21:46 -0500 (EST) Message-Id: <200003151121.GAA28077@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-failover-06.txt Date: Wed, 15 Mar 2000 06:21:46 -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 Failover Protocol Author(s) : R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil, M. Dooley, A. Kapur Filename : draft-ietf-dhc-failover-06.txt Pages : 119 Date : 14-Mar-00 DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. This document is a substantial reorganization as well as a technical and editorial revision of draft-ietf-dhc-failover-05.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-06.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-failover-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-failover-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-failover-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314132359.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Mar 15 06:26:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00071 for ; Wed, 15 Mar 2000 06:26:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA01229; Wed, 15 Mar 2000 06:26:14 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA10456 for ; Wed, 15 Mar 2000 06:21:54 -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 GAA28107; Wed, 15 Mar 2000 06:21:51 -0500 (EST) Message-Id: <200003151121.GAA28107@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-nextserver-02.txt Date: Wed, 15 Mar 2000 06:21:50 -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 Next Server Option Author(s) : J. Privat, M. Borella Filename : draft-ietf-dhc-nextserver-02.txt Pages : Date : 14-Mar-00 This proposal allows host configuration to be split between two different address servers, potentially under different administration. This ability may be useful to satisfy specific regulatory, operational or business model requirements, as well as to provide support for secondary address servers. This draft proposes a new DHCP option called the DHCP Next Server option. A DHCP server can use this option to redirect clients to a secondary server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nextserver-02.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-nextserver-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-nextserver-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314132409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Mar 15 23:32:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14095 for ; Wed, 15 Mar 2000 23:32:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA22340; Wed, 15 Mar 2000 23:31:55 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id XAA01046 for ; Wed, 15 Mar 2000 23:31:36 -0500 (EST) Received: from droms-mac (pm3mi2-14.uplink.net [209.173.86.63]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id XAA02119 for ; Wed, 15 Mar 2000 23:31:34 -0500 (EST) Message-Id: <4.2.2.20000315200901.00aa2940@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 20:09:49 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHCP options for SIP (reminder) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN WG members - this is a reminder that the last call on draft-nair-sip-dhcp-00.txt expires this coming Friday, 3/17. - Ralph ===== The SIP WG has developed a proposal for DHCP options to carry SIP configuration information. The DHC WG reviewed a preliminary version of this document, draft-nair-sip-dhcp-00.txt. The authors have revised the document based on DHC WG input, and would like to submit the new proposal into the standards track. The SIP WG would like to "fast track" this proposal, as it is not complex, the I-D is short and the authors have revised the proposal based on DHC WG input. To move the proposal forward efficiently, the SIP WG has issued a WG last call on the current draft, draft-ietf-sip-dhcp-00.txt. In parallel with the SIP WG last call, I am issuing a DHC WG last call on the draft. Please review the revised document and post your comments to the dhcp-v4@bucknell.edu mailing list. The DHC WG last call will end on March 17. - Ralph Droms From owner-dhcp-v4@bucknell.edu Thu Mar 16 16:11:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20288 for ; Thu, 16 Mar 2000 16:11:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA17380; Thu, 16 Mar 2000 16:11:27 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA06044 for ; Thu, 16 Mar 2000 16:10:46 -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 QAA19811; Thu, 16 Mar 2000 16:10:42 -0500 (EST) Message-Id: <200003162110.QAA19811@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-csr-01.txt Date: Thu, 16 Mar 2000 16:10:41 -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 : The Classless Static Route Option for DHCP Author(s) : T. Lemon Filename : draft-ietf-dhc-csr-01.txt Pages : Date : 15-Mar-00 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-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-csr-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-csr-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: <20000315132202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132202.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 17 08:21:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21625 for ; Fri, 17 Mar 2000 08:21:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA31624; Fri, 17 Mar 2000 08:20:49 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA05614 for ; Fri, 17 Mar 2000 08:20:28 -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 IAA21065; Fri, 17 Mar 2000 08:20:27 -0500 (EST) Message-Id: <200003171320.IAA21065@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-loadb-01.txt Date: Fri, 17 Mar 2000 08:20:26 -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 : DHC load balancing algorithm Author(s) : B. Volz, R. Stevens, T. Lemon, S. Gonczi Filename : draft-ietf-dhc-loadb-01.txt Pages : 9 Date : 16-Mar-00 This draft proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration. The draft proposes a computable server selection mechanism when multiple DHCP servers are available to service DHCP clients. In addition, it offers the same mechanism select the target server of a forwarding agent such as a BOOTP relay. The possible benefits overlap with those enumerated in [SSO-03], but this draft does not require any DHCP client modifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-loadb-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-loadb-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-loadb-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: <20000316143826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-loadb-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-loadb-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316143826.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 17 08:24:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22752 for ; Fri, 17 Mar 2000 08:24:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA13926; Fri, 17 Mar 2000 08:24:13 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA02544 for ; Fri, 17 Mar 2000 08:20:33 -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 IAA21119; Fri, 17 Mar 2000 08:20:32 -0500 (EST) Message-Id: <200003171320.IAA21119@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-dhcp-dns-12.txt Date: Fri, 17 Mar 2000 08:20:31 -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 : Interaction between DHCP and DNS Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-dhcp-dns-12.txt Pages : 19 Date : 16-Mar-00 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies how DHCP clients and servers should use the Dynamic DNS Updates mechanism in [RFC2136] to update the DNS name to address and address to name mappings so that the mappings for DHCP clients will be consistent with the IP addresses that the clients acquire via DHCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcp-dns-12.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-dhcp-dns-12.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-dhcp-dns-12.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: <20000316144036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcp-dns-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144036.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 17 08:24:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22834 for ; Fri, 17 Mar 2000 08:24:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA05902; Fri, 17 Mar 2000 08:24:28 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA27738 for ; Fri, 17 Mar 2000 08:20:38 -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 IAA21145; Fri, 17 Mar 2000 08:20:36 -0500 (EST) Message-Id: <200003171320.IAA21145@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-option-review-and-namespace-02.txt Date: Fri, 17 Mar 2000 08:20:36 -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 : New Option Review Guidelines and Additional Option Namespace Author(s) : M. Carney Filename : draft-ietf-dhc-option-review-and-namespace-02.txt Pages : 14 Date : 16-Mar-00 This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-review-and-namespace-02.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-option-review-and-namespace-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-option-review-and-namespace-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144053.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 17 12:34:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03341 for ; Fri, 17 Mar 2000 12:34:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA00865; Fri, 17 Mar 2000 12:34:20 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA19598 for ; Fri, 17 Mar 2000 12:33:58 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26553 for ; Fri, 17 Mar 2000 09:33:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA15447 for ; Fri, 17 Mar 2000 09:33:36 -0800 (PST) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e2HHXYQ705332 for ; Fri, 17 Mar 2000 09:33:34 -0800 (PST) Date: Fri, 17 Mar 2000 09:33:13 -0800 (PST) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: Re: I-D ACTION:draft-ietf-dhc-option-review-and-namespace-02.txt To: DHCPv4 discussion list In-Reply-To: "Your message with ID" <200003171320.IAA21145@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Differences over version 01: 1) Message types are considered in the guideline categories as options are. 2) A new RFC 2131 style option is defined, the RFC TBD parameter request list, which permits RFC TBD clients to request RFC TBD options. 3) The version option makes explicit the required features (additions to table 3 and 5 of rfc 2131, as well as some new message types), thus aiding in the validation and identification of DHCP messages. 4) The open issues section has been removed. Mike Carney SNT Internet Engineering Sun Microsystems, Inc. (650) 786-4171 Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 From owner-dhcp-v6@bucknell.edu Fri Mar 17 14:17:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16783 for ; Fri, 17 Mar 2000 14:17:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA06321; Fri, 17 Mar 2000 14:03:11 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA00015 for ; Fri, 17 Mar 2000 14:02:59 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08556 for ; Fri, 17 Mar 2000 11:02:58 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA06596 for ; Fri, 17 Mar 2000 11:02:57 -0800 (PST) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e2HJ2qQ720229 for ; Fri, 17 Mar 2000 11:02:53 -0800 (PST) Date: Fri, 17 Mar 2000 11:02:30 -0800 (PST) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: #1, DAD, DHCP clients and servers... To: DHCPv6 discussion list In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi folks, I've uncovered a few issues when writing the new DHCPv6 drafts that I'd like to get the opinion of the WG on. I'm sending each issue in a separate message thread, to facilitate the discussion. 1) draft-ietf-dhc-dhcpv6-14.txt states that a client is to perform Duplicate Address Detection (DAD) on IP addresses it receives from DHCP server(s). That prevents multiple machines from using the same address on the link, but there isn't any mechanism for notifying the DHCP server(s) that the IP address it handed out is already in use. DHCPv4 has the DHCPDECLINE mechanism for this purpose. When I asked a few folks about this problem, I was told that the IP addresses given out by DHCPv6 servers will always include the client interface's interface identifier, and thus the address should already be unique, since uniqueness is determined by the interface identifier, a'la stateless address autoconf. It seems to me that one of the features of DHCPv6 should be the ability to allocate IP addresses independent of an interface's interface ID. Otherwise, I feel we're unnecessarily limiting the protocol. If we want to enable DHCPv6 to return IP addresses independent of the client's interface ID, then I think we need a mechanism for DHCP clients to use to inform servers of IP address collisions. Thus: a) Do we want to enable DHCPv6 to return IP addresses independent of client interface ID? b) If (a) is YES, then is it important for clients to notify servers of the address collision (or more generally, resource collision)? c) If (b) is YES, then the mechanism I propose is similar to DHCPv4. We add a new message type, the Decline message, and a the client would include an IP address extension with the client IP address field set to the duplicate address, the 'C' bit set, and the status field would contain a TBD value informing the server that the IP address is already in use. Please feel free to propose other solutions. Mike Carney SNT Internet Engineering Sun Microsystems, Inc. (650) 786-4171 Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 From owner-dhcp-v6@bucknell.edu Fri Mar 17 17:10:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26716 for ; Fri, 17 Mar 2000 17:10:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA11352; Fri, 17 Mar 2000 17:04:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA04136 for ; Fri, 17 Mar 2000 17:04:27 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17609 for ; Fri, 17 Mar 2000 14:04:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA25150 for ; Fri, 17 Mar 2000 14:04:26 -0800 (PST) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e2HM4NQ749782 for ; Fri, 17 Mar 2000 14:04:24 -0800 (PST) Date: Fri, 17 Mar 2000 14:04:02 -0800 (PST) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: Re: #1, DAD, DHCP clients and servers... (Fwd) To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <200003171939.LAA01678@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >----------------Begin Forwarded Message----------------< Date: Fri, 17 Mar 2000 11:39:54 -0800 (PST) From: "Tim Hartrick" Subject: Re: #1, DAD, DHCP clients and servers... To: Michael.Carney@eng.sun.com Mike, For what it is worth my two cents.. > Thus: > > a) Do we want to enable DHCPv6 to return IP addresses independent of > client interface ID? > Yes. > b) If (a) is YES, then is it important for clients to notify servers of > the address collision (or more generally, resource collision)? > Yes. Note that one of the things that DAD does in addition to finding IPv6 address collisions is detect link-layer address collisions. While this is a extremely rare occurence the protocol should be resilient enough to handle the situation. > c) If (b) is YES, then the mechanism I propose is similar to DHCPv4. We > add a new message type, the Decline message, and a the client would > include an IP address extension with the client IP address field set to > the duplicate address, the 'C' bit set, and the status field would > contain a TBD value informing the server that the IP address is already > in use. Please feel free to propose other solutions. > I am not qualified to pass judgement but this sounds reasonable. tim >----------------End Forwarded Message----------------< From owner-dhcp-v6@bucknell.edu Sat Mar 18 12:54:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21482 for ; Sat, 18 Mar 2000 12:54:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA17667; Sat, 18 Mar 2000 12:52:08 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA13766 for ; Sat, 18 Mar 2000 12:51:58 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07022 for ; Sat, 18 Mar 2000 09:51:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA02065 for ; Sat, 18 Mar 2000 09:51:57 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e2IHptQ828528; Sat, 18 Mar 2000 09:51:56 -0800 (PST) Date: Sat, 18 Mar 2000 09:15:22 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: #1, DAD, DHCP clients and servers... To: DHCPv6 discussion list Cc: DHCPv6 discussion list In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > a) Do we want to enable DHCPv6 to return IP addresses independent of > client interface ID? Yes. In some cases a site might wish to "hide" the interface ID (it tells who manufactured the EThernet card if nothing else). Also, in certain cases (maybe in the future) sites might wish to have denser allocation by not giving a /64 to every subnet. Being able to use DHCP (since stateless addrconf can't do it) seems like useful 'insurance'. > b) If (a) is YES, then is it important for clients to notify servers of > the address collision (or more generally, resource collision)? At a minimum the clients must be able to get a different address. And for operational reasons I assume the DHCP server (and admin) needs to be notified of the duplication. Erik From owner-dhcp-v6@bucknell.edu Mon Mar 20 05:48:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28245 for ; Mon, 20 Mar 2000 05:48:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA18285; Mon, 20 Mar 2000 05:44:55 -0500 (EST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA15555 for ; Mon, 20 Mar 2000 05:44:45 -0500 (EST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA51186; Mon, 20 Mar 2000 11:43:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA12500; Mon, 20 Mar 2000 11:43:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA09366; Mon, 20 Mar 2000 11:47:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200003201047.LAA09366@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: #1, DAD, DHCP clients and servers... In-reply-to: Your message of Fri, 17 Mar 2000 11:02:30 PST. Date: Mon, 20 Mar 2000 11:47:40 +0100 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: a) Do we want to enable DHCPv6 to return IP addresses independent of client interface ID? => yes, IMHO it is one of the reasons we need DHCPv6. b) If (a) is YES, then is it important for clients to notify servers of the address collision (or more generally, resource collision)? => yes because the client will need to get another address and the manager a red window with an error message (I suppose the manager manages the DHCPv6 server in place of a zillion of individual hosts :-). c) If (b) is YES, then the mechanism I propose is similar to DHCPv4. We add a new message type, the Decline message, and a the client would include an IP address extension with the client IP address field set to the duplicate address, the 'C' bit set, and the status field would contain a TBD value informing the server that the IP address is already in use. Please feel free to propose other solutions. => It should be fine to have as many as possible infos about the collision? Perhaps an error message with suitable extensions is better (ie this is more an error case than a retry one). Regards Francis.Dupont@enst-bretagne.fr PS: I agree with Tim and Erik. From owner-dhcp-v6@bucknell.edu Mon Mar 20 08:05:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17565 for ; Mon, 20 Mar 2000 08:05:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA17299; Mon, 20 Mar 2000 08:01:23 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA17483 for ; Mon, 20 Mar 2000 08:01:11 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA05285 for ; Mon, 20 Mar 2000 08:00:39 -0500 Message-Id: <200003201300.IAA05285@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: #1, DAD, DHCP clients and servers... Date: Mon, 20 Mar 2000 08:00:39 -0500 From: Thomas Narten 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 > When I asked a few folks about this problem, I was told that the IP > addresses given out by DHCPv6 servers will always include the client > interface's interface identifier, and thus the address should already be > unique, since uniqueness is determined by the interface identifier, a'la > stateless address autoconf. This would appear to be a misconception. AFAIK, its always been assumed that a DHCP server can assign whatever addresses it wants just as DHCPv4 does today. > It seems to me that one of the features of DHCPv6 should be the ability > to allocate IP addresses independent of an interface's interface ID. > Otherwise, I feel we're unnecessarily limiting the protocol. Agree 100%. Thomas From owner-dhcp-v4@bucknell.edu Mon Mar 20 09:20:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19690 for ; Mon, 20 Mar 2000 09:20:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA04188; Mon, 20 Mar 2000 09:20:10 -0500 (EST) Received: from fs-sd-exch1.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA02620; Mon, 20 Mar 2000 09:19:42 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Mar 2000 06:18:09 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B10891599A088@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Cc: droms@bucknell.edu, mpatrick@dma.isg.mot.com Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Mon, 20 Mar 2000 06:18:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I spoke with with Michael Patrick on the phone Friday (3/17). We agreed on the following minor changes to move this draft to "Proposed Standard" without delay. These changes allow the draft to be used in non-routed-front-end applications, such as DSL: 1. 2nd paragraph in section 2.1, remove the reference to BOOTP which contradicts RFCs 1534, 2131, and 2132. The BOOTP exclusion also prevents working with thousands of installed BOOTP clients. Since this draft is transparent to BOOTP vs DHCP, it applies equally to both of them. This change to the draft introduces no interoperability issues, and at most requires removal of special forwarding-agent code that filtered out the BOOTP case, which is now handled the same as all other options. 2. 3rd paragraph in section 2.1: Change "Relay agents receiving a DHCP packet with giaddr set to zero ..." to something like "Relay agents receiving a DHCP packet from an untrusted source with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count." Let's move to Proposed Standard with these small (but important) changes. Other clarifications can be made in moving from Proposed Standard to Draft Standard. I appreciate Mr. Patrick's attention to these issues, and apologize again for my late entry into the discussion. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks From owner-dhcp-v6@bucknell.edu Mon Mar 20 09:40:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28832 for ; Mon, 20 Mar 2000 09:40:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA30654; Mon, 20 Mar 2000 09:39:36 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA15372 for ; Mon, 20 Mar 2000 09:39:25 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA04505; Mon, 20 Mar 2000 09:39:22 -0500 (EST) Message-Id: <4.2.2.20000320093748.00a51590@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 20 Mar 2000 09:39:16 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: #1, DAD, DHCP clients and servers... In-Reply-To: References: <"Your message with ID" 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 At 11:02 AM 3/17/00 -0800, Michael W. Carney wrote: >a) Do we want to enable DHCPv6 to return IP addresses independent of >client interface ID? *Yes*. >b) If (a) is YES, then is it important for clients to notify servers of >the address collision (or more generally, resource collision)? Yes - although I'm not sure what other resources might "collide" at this point... >c) If (b) is YES, then the mechanism I propose is similar to DHCPv4. We >add a new message type, the Decline message, and a the client would >include an IP address extension with the client IP address field set to >the duplicate address, the 'C' bit set, and the status field would >contain a TBD value informing the server that the IP address is already >in use. Please feel free to propose other solutions. A Decline message seems like the right solution. - Ralph From owner-dhcp-v4@bucknell.edu Tue Mar 21 10:38:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27010 for ; Tue, 21 Mar 2000 10:38:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA22282; Tue, 21 Mar 2000 10:37:43 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA21252; Tue, 21 Mar 2000 10:37:00 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA05210; Tue, 21 Mar 2000 10:36:59 -0500 (EST) Message-Id: <4.2.2.20000321094445.00a5fdc0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 10:36:55 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG meetings in Adelaide Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN After a recent conversation, the DHCPv6 authors and I have decided to take discussion of the DHCPv6 draft off the WG agenda for our meetings in Adelaide. The authors and I will get together in Adelaide to develop a timeline and milestones to be met prior to the WG meeting in Pittsburgh. As soon as we finalize those plans, we will publish them to the DHCPv6 mailing list. Because of the long list of DHCPv4 agenda items for Adelaide, we will use all of the Tuesday morning WG meeting and as much of the Wednesday afternoon WG meeting as necessary for DHCPv4. If you are currently on the DHCPv4 agenda, and would like to be moved to Wednesday afternoon, please let me know. I will publish a revised agenda, indicating which topics will be scheduled for each of the two meetings, later this afternoon. - Ralph From owner-dhcp-v6@bucknell.edu Tue Mar 21 10:40:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28165 for ; Tue, 21 Mar 2000 10:40:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA24774; Tue, 21 Mar 2000 10:37:13 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA21252; Tue, 21 Mar 2000 10:37:00 -0500 (EST) Received: from droms-mac (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA05210; Tue, 21 Mar 2000 10:36:59 -0500 (EST) Message-Id: <4.2.2.20000321094445.00a5fdc0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 10:36:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: WG meetings in Adelaide 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 After a recent conversation, the DHCPv6 authors and I have decided to take discussion of the DHCPv6 draft off the WG agenda for our meetings in Adelaide. The authors and I will get together in Adelaide to develop a timeline and milestones to be met prior to the WG meeting in Pittsburgh. As soon as we finalize those plans, we will publish them to the DHCPv6 mailing list. Because of the long list of DHCPv4 agenda items for Adelaide, we will use all of the Tuesday morning WG meeting and as much of the Wednesday afternoon WG meeting as necessary for DHCPv4. If you are currently on the DHCPv4 agenda, and would like to be moved to Wednesday afternoon, please let me know. I will publish a revised agenda, indicating which topics will be scheduled for each of the two meetings, later this afternoon. - Ralph From owner-dhcp-v4@bucknell.edu Tue Mar 21 14:19:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20810 for ; Tue, 21 Mar 2000 14:19:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA19544; Tue, 21 Mar 2000 14:18:45 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA29417 for ; Tue, 21 Mar 2000 14:18:04 -0500 (EST) Received: from droms-mac (pm3mi1-0.uplink.net [209.173.86.1]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA05370 for ; Tue, 21 Mar 2000 14:18:01 -0500 (EST) Message-Id: <4.2.2.20000321140701.00a668e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 14:17:50 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Agenda for WG meeting in Adelaide Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4779345==_.ALT" Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --=====================_4779345==_.ALT Content-Type: text/plain; charset="us-ascii" The agenda is now available at http://www.dhcp.org/0003-meeting.html and below. Please contact me if you expected to be on the agenda and you're not, or if you would like to switch meeting times or if you would like to be added to the agenda. Note that the I-Ds for DHCP authentication and the domain search option are not currently available on line. - Ralph ===== 3/28, 0900-1130 - DHCPv4 agenda items Use of DHCP for configuration of IPSEC tunnel mode Bernard Aboba, 10 minutes Use of DHCP for configuring multicast DNS behavior Bernard Aboba, 10 minutes DHCP Next Server Option Mike Borella, 10 minutes DHCP authentication Ralph Droms, 10 minutes Domain search option Ralph Droms (for Pratik Gupta), 10 minutes Requirements for Extending DHCP into New Environments Subir Das, 20 minutes Authentication, Authorization, and Accounting Subir Das, 10 minutes Requirements for Roaming Nodes using DHCP Dynamic Configuration of IPv4 link-local addresses Ralph Droms (with Cheshire) Automatically Choosing an IP Address in an Stuart Cheshire, 10 minutes Ad-Hoc IPv4 Network DHCP reconfigure extension P.De Schrijver, 10 minutes Classless Static Routes option Ted Lemon, 10 minutes 3/18, 1330-1530 - DHCPv4 issues Interaction between DHCP and DNS Ted Lemon/Ralph Droms (?), 15 minutes Kerberos V Authentication Mode for P. Lalwaney/S. Medvinsky, 10 minutes Uninitialized Clients DHCP Lease Query Rich Woundy, 15 minutes DHCP Option for PacketCable VoIP Client Configuration Burcak Beser, 15 minutes --=====================_4779345==_.ALT Content-Type: text/html; charset="us-ascii" The agenda is now available at http://www.dhcp.org/0003-meeting.html and below.

Please contact me if you expected to be on the agenda and you're not, or if you
would like to switch meeting times or if you would like to be added to the agenda.

Note that the I-Ds for DHCP authentication and the domain search option are not
currently available on line.

- Ralph

=====

3/28, 0900-1130 - DHCPv4 agenda items

Use of DHCP for configuration of IPSEC tunnel mode     Bernard Aboba, 10 minutes
Use of DHCP for configuring multicast DNS behavior     Bernard Aboba, 10 minutes
DHCP Next Server Option                                Mike Borella, 10 minutes
DHCP authentication                                    Ralph Droms, 10 minutes
Domain search option                                   Ralph Droms (for Pratik Gupta), 10 minutes
Requirements for Extending DHCP into New Environments  Subir Das, 20 minutes
Authentication, Authorization, and Accounting          Subir Das, 10 minutes
Requirements for Roaming Nodes using DHCP   
Dynamic Configuration of IPv4 link-local addresses     Ralph Droms (with Cheshire)
Automatically Choosing an IP Address in an             Stuart Cheshire, 10 minutes
Ad-Hoc IPv4 Network                        
DHCP reconfigure extension                             P.De Schrijver, 10 minutes
Classless Static Routes option                         Ted Lemon, 10 minutes


3/18, 1330-1530 - DHCPv4 issues

Interaction between DHCP and DNS                       Ted Lemon/Ralph Droms (?), 15 minutes
Kerberos V Authentication Mode for                     P. Lalwaney/S. Medvinsky, 10 minutes
Uninitialized Clients            
DHCP Lease Query                                       Rich Woundy, 15 minutes
DHCP Option for PacketCable VoIP Client Configuration  Burcak Beser, 15 minutes
--=====================_4779345==_.ALT-- From owner-dhcp-v4@bucknell.edu Tue Mar 21 19:43:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20589 for ; Tue, 21 Mar 2000 19:43:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA07658; Tue, 21 Mar 2000 19:43:04 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA00548; Tue, 21 Mar 2000 19:42:53 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71] (may be forged)) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA08607; Tue, 21 Mar 2000 07:10:20 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id TAA00868; Tue, 21 Mar 2000 19:42:45 -0500 (EST) Message-Id: <200003220042.TAA00868@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Agenda for WG meeting in Adelaide In-Reply-To: Message from Ralph Droms of "Tue, 21 Mar 2000 14:17:50 EST." <4.2.2.20000321140701.00a668e0@mail.bucknell.edu> Date: Tue, 21 Mar 2000 19:42:45 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Kerberos V Authentication Mode for P. Lalwaney/S. Medvinsky, 10 minutes Is this related to Bernie Aboba's draft? _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Mar 23 07:52:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19628 for ; Thu, 23 Mar 2000 07:52:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA06681; Thu, 23 Mar 2000 07:51:19 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA18181; Thu, 23 Mar 2000 07:51:09 -0500 (EST) Received: from droms-mac (pm3mi2-35.uplink.net [209.173.86.84]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA08248; Thu, 23 Mar 2000 07:51:05 -0500 (EST) Message-Id: <4.2.2.20000323074954.00a67e80@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 23 Mar 2000 07:50:55 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meeting agenda for Adelaide Cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Agenda also available at http://www.dhcp.org/0003-meeting.html) 3/28, 0900-1130 - DHCPv4 agenda items ------------------------------------- Use of DHCP for configuration of IPSEC tunnel mode Bernard Aboba, 10 minutes Use of DHCP for configuring multicast DNS behavior Bernard Aboba, 10 minutes DHCP Next Server Option Mike Borella, 10 minutes DHCP authentication Ralph Droms, 10 minutes Domain search option Ralph Droms (for Pratik Gupta) 10 minutes Requirements for Extending DHCP into Subir Das, 20 minutes New Environments Authentication, Authorization, and Accounting Subir Das, 10 minutes Requirements for Roaming Nodes using DHCP Dynamic Configuration of IPv4 link-local addresses Stuart Cheshire, Ralph Automatically Choosing an IP Address in an Droms, 20 minutes Ad-Hoc IPv4 Network DHCP reconfigure extension P.De Schrijver, 10 minutes Classless Static Routes option Ted Lemon, 10 minutes 3/29, 1330-1530 - DHCPv4 issues ------------------------------- Interaction between DHCP and DNS Ted Lemon/Ralph Droms 15 minutes Kerberos V Authentication Mode for Uninitialized P. Lalwaney Clients S. Medvinsky, 10 minutes DHCP Lease Query Rich Woundy, 15 minutes DHCP Option for PacketCable VoIP Client Burcak Beser, 15 minutes Configuration From owner-dhcp-v6@bucknell.edu Thu Mar 23 07:55:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20460 for ; Thu, 23 Mar 2000 07:55:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA00378; Thu, 23 Mar 2000 07:51:14 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA18181; Thu, 23 Mar 2000 07:51:09 -0500 (EST) Received: from droms-mac (pm3mi2-35.uplink.net [209.173.86.84]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA08248; Thu, 23 Mar 2000 07:51:05 -0500 (EST) Message-Id: <4.2.2.20000323074954.00a67e80@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 23 Mar 2000 07:50:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meeting agenda for Adelaide Cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu 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 (Agenda also available at http://www.dhcp.org/0003-meeting.html) 3/28, 0900-1130 - DHCPv4 agenda items ------------------------------------- Use of DHCP for configuration of IPSEC tunnel mode Bernard Aboba, 10 minutes Use of DHCP for configuring multicast DNS behavior Bernard Aboba, 10 minutes DHCP Next Server Option Mike Borella, 10 minutes DHCP authentication Ralph Droms, 10 minutes Domain search option Ralph Droms (for Pratik Gupta) 10 minutes Requirements for Extending DHCP into Subir Das, 20 minutes New Environments Authentication, Authorization, and Accounting Subir Das, 10 minutes Requirements for Roaming Nodes using DHCP Dynamic Configuration of IPv4 link-local addresses Stuart Cheshire, Ralph Automatically Choosing an IP Address in an Droms, 20 minutes Ad-Hoc IPv4 Network DHCP reconfigure extension P.De Schrijver, 10 minutes Classless Static Routes option Ted Lemon, 10 minutes 3/29, 1330-1530 - DHCPv4 issues ------------------------------- Interaction between DHCP and DNS Ted Lemon/Ralph Droms 15 minutes Kerberos V Authentication Mode for Uninitialized P. Lalwaney Clients S. Medvinsky, 10 minutes DHCP Lease Query Rich Woundy, 15 minutes DHCP Option for PacketCable VoIP Client Burcak Beser, 15 minutes Configuration From owner-dhcp-v4@bucknell.edu Wed Mar 29 12:27:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22903 for ; Wed, 29 Mar 2000 12:27:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA05539; Wed, 29 Mar 2000 12:26:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA02803 for ; Wed, 29 Mar 2000 12:26:06 -0500 (EST) Received: from mjs-pc (mjs-pc.cisco.com [172.27.181.69]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA05605; Wed, 29 Mar 2000 12:25:15 -0500 (EST) Message-Id: <4.2.0.58.20000329115225.01c7d100@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 29 Mar 2000 12:26:24 -0500 To: DHCPv4 discussion list From: Mark Stapp Subject: Re: Interaction between DHCP and DNS Cc: "'dhcp-v4@bucknell.edu'" , Yang Jin-JINYANG1 , Shi Rong-rongshi1 In-Reply-To: <09C1525B7197D3118A4D0008C7E6EEE01D3F0F@zuk28exm05.ecid.cig .mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: mjs@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jin, Thanks for your questions; I've replied inline. At 02:49 PM 3/28/00 +0100, Yang Jin-JINYANG1 wrote: [...] >Assuming Host-A's IP address is assigned dynamically by DHCP and DNS is >updated to reflect this new mapping, how would the following scenarios work: > >(1) After Host-A log-off, will DNS be informed? That depends. If the client at A performed its own DNS update, it may try to perform another DNS update as it goes down in order to remove DNS information. But even if it tries, it may not succeed: it may not be able to reach the DNS server at that moment, or it may be shut down so rapidly that it doesn't have time to attempt an update. If the DHCP server performed DNS updates for the client, the server will not even know that the client has logged off unless the client sends a DHCPRELEASE message as it shuts down. That may not be desirable in all installations: it may be costly to the DHCP and DNS servers to remove lease bindings and DNS records each time a client reboots, or is shut down overnight. Since the DHCP server is likely to be available most of the time, it's probably easier for it to do the house-cleaning as leases expire or are released, but that's not a requirement, and different sites may develop different policies. There is an administrative issue, however. If the client is *permanently* shutting down, and not just being put to sleep overnight, many administrators will want to remove its DNS name so that "stale" DNS data doesn't accumulate indefinitely. The draft tries to describe some of the administrative policies that I could imagine, or that were offered by others. The dhcp-dns draft doesn't attempt to tell administrators what policy to apply in their nets, it just tries to establish a consistent way of adding information that they and their dhcp clients and servers can use to apply _some_ policy. >(2) Host-B gets A's IP address via DNS and cached it locally. Then Host-A >log-off but Host-B does not know and continually sends packets to A's IP >address. Is this a concern? DNS isn't really a database of currently connected hosts, of course, so the presence of a name in the DNS isn't a guarantee that a host is present and reachable on the net. My statically-configured workstations may not always be connected, and they may not always be reachable from every other host. So no, in general the concerns aren't much different for dhcp and non-dhcp clients. The issue of dns ttls has been raised in the course of dhcp and dns discussions about the dhcp-dns draft. The draft doesn't contain strict rules that must be applied, but it does discuss dns ttls, and suggest a couple of possible ways to establish reasonable ttls. Regards, Mark From owner-dhcp-v4@bucknell.edu Thu Mar 30 11:26:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17551 for ; Thu, 30 Mar 2000 11:26:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA11963; Thu, 30 Mar 2000 11:26:24 -0500 (EST) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA02253 for ; Thu, 30 Mar 2000 11:24:49 -0500 (EST) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2448.0) id ; Thu, 30 Mar 2000 10:29:43 -0600 Message-ID: <8E93DF8429F8D311966B0060971DA17C1E8FCC@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Subject: DHCP APIs? Date: Thu, 30 Mar 2000 10:29:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: revans@sta.samsung.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Newbie question... Are there any APIs defined for accessing DHCP ? For example, I might want to write an application to query DHCP for IP addresses, DNS servers, etc. based on various client identifiers - basically writing my own DHCP client. Is there any way to do this? References? Thanks, and my apologies if the answer is obvious. - ================================= Bob Evans Distributed Processing Environment Team Network Systems Lab Samsung Telecommunications America 1130 E. Arapaho Road Richardson, TX 75081 VOX 972-761-7725 FAX 7799 From owner-dhcp-v4@bucknell.edu Thu Mar 30 11:48:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17731 for ; Thu, 30 Mar 2000 11:48:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA05159; Thu, 30 Mar 2000 11:48:49 -0500 (EST) Received: from dieselmeat.bucknell.edu (jgoldsch.resnet.bucknell.edu [134.82.88.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA07726 for ; Thu, 30 Mar 2000 11:47:34 -0500 (EST) Received: from localhost (jgoldsch@localhost) by dieselmeat.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA05759; Thu, 30 Mar 2000 11:47:15 -0500 X-Authentication-Warning: dieselmeat.bucknell.edu: jgoldsch owned process doing -bs Date: Thu, 30 Mar 2000 11:47:15 -0500 (EST) From: Jason Goldschmidt X-Sender: jgoldsch@dieselmeat To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP APIs? In-Reply-To: <8E93DF8429F8D311966B0060971DA17C1E8FCC@stanmsr4.telecom.sna.samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: jgoldsch@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bob, You might want to check out a project called JDHCP: http://www.eg.bucknell.edu/~jgoldsch/dhcp/ It is an API for DHCP written in Java. -Jason jgoldsch@acm.org On Thu, 30 Mar 2000, Bob Evans wrote: > Newbie question... > Are there any APIs defined for accessing DHCP ? For example, I might want > to write an application to query DHCP for IP addresses, DNS servers, etc. > based on various client identifiers - basically writing my own DHCP client. > Is there any way to do this? References? > > Thanks, and my apologies if the answer is obvious. > - > ================================= > Bob Evans > Distributed Processing Environment Team > Network Systems Lab > Samsung Telecommunications America > 1130 E. Arapaho Road > Richardson, TX 75081 > VOX 972-761-7725 FAX 7799 > > > *************************************) Jason Goldschmidt jgoldsch@acm.org *) http://coral.bucknell.edu/~jgoldsch *) "My Reality Check Bounced" *) -Scott Adams *) *************************************) From owner-dhcp-v4@bucknell.edu Thu Mar 30 19:21:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23840 for ; Thu, 30 Mar 2000 19:20:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA00221; Thu, 30 Mar 2000 19:20:32 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA19517 for ; Thu, 30 Mar 2000 19:18:58 -0500 (EST) Received: from grosse.manhattan.fugue.com (dhcp-32-119.ietf.connect.com.au [169.208.32.119]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id GAA16309; Thu, 30 Mar 2000 06:46:23 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id RAA00874; Thu, 30 Mar 2000 17:18:50 -0700 (MST) Message-Id: <200003310018.RAA00874@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP APIs? In-Reply-To: Message from Bob Evans of "Thu, 30 Mar 2000 10:29:37 CST." <8E93DF8429F8D311966B0060971DA17C1E8FCC@stanmsr4.telecom.sna.samsung.com> Date: Thu, 30 Mar 2000 17:18:50 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Are there any APIs defined for accessing DHCP ? For example, I might want > to write an application to query DHCP for IP addresses, DNS servers, etc. > based on various client identifiers - basically writing my own DHCP client. > Is there any way to do this? References? There is a draft that defines a mechanism for using LDAP to access the DHCP server's internal state, and also one for using SNMP. This are available at ftp://ftp.ietf.org/internet-drafts, and I think the files are draft-ietf-dhc-ldap-schema-??.txt and draft-ietf-dhc-snmp-mib-??.txt, or something like that. The ISC DHCP server also includes an API for accessing the internal server state called OMAPI, which is brand new and for which there's no real documentation yet. :'{ _MelloN_