From owner-dhcp-v4@bucknell.edu Thu Feb 1 07:01:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24016 for ; Thu, 1 Feb 2001 07:01:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11Btha13747; Thu, 1 Feb 2001 06:55:43 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11BtXa09105 for ; Thu, 1 Feb 2001 06:55: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 GAA23785; Thu, 1 Feb 2001 06:55:27 -0500 (EST) Message-Id: <200102011155.GAA23785@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-authentication-16.txt Date: Thu, 01 Feb 2001 06:55:27 -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 for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-16.txt Pages : 17 Date : 31-Jan-01 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-16.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-authentication-16.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-authentication-16.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: <20010131133725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-authentication-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010131133725.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Thu Feb 1 10:04:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28753; Thu, 1 Feb 2001 10:04:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11Ev3a08425; Thu, 1 Feb 2001 09:57:03 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11Ev1a02902 for ; Thu, 1 Feb 2001 09:57:01 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18288; Thu, 1 Feb 2001 09:56:43 -0500 (EST) Message-Id: <4.3.1.2.20010201094525.00b126b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 01 Feb 2001 09:56:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Status of DHCPv6 spec Cc: narten@RALEIGH.IBM.COM, Erik.Nordmark@eng.sun.com 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 Well, I promised to have a rev of the spec done by yesterday (1/31), and I didn't make the deadline. I will have the revised spec submitted by next Monday (2/5). At the WG meeting in San Diego, we planned a design team teleconference to review the -17 for the week of 2/12. I propose we hold that teleconference noon-3PM on 2/15. If you want to attend the teleconference, but absolutely aren't available at that time, please let me know by this 5PM, 2/2. If you do want to reschedule, it would be helpful if you could give me a list of alternatives dates (I'd like to stick with noon-3PM to accommodate participants in as many timezones as possible). As always, Cisco will be happy to host the in-person part of the teleconference here in Chelmsford. We will set up dial-in access and will be willing to reimburse anyone for toll calls incurred in dialing in. If you'd like to come to Chelmsford for the teleconference, let me know so we can arrange for access to the conference room. There are a couple of outstanding issues we need to discuss. I'll kick off those discussions in separate e-mail. If you have any other input for us based on the -16 draft, we can still get those changes into the -17 draft. - Ralph From owner-dhcp-v4@bucknell.edu Thu Feb 1 10:37:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29469 for ; Thu, 1 Feb 2001 10:37:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11FVra24137; Thu, 1 Feb 2001 10:31:53 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11FVea11058 for ; Thu, 1 Feb 2001 10:31:40 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 10:31:22 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Thu, 1 Feb 2001 10:31:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Subir, First of all sorry I disappeared but I was away on business. I am not sure I understand your argument regarding Application Layer authentication. It seams to me that this will eliminate the authentication per network layer protocol (v4/v6) but will require it per application....which I guess is even worst :-) ...unless I missed your point... George -----Original Message----- From: Subir Das [mailto:subir@research.telcordia.com] Sent: Tuesday, January 30, 2001 8:07 PM To: aboba@internaut.com Cc: DHCPv4 discussion list; urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt Bernard, Here is an attempt to answer your question: 1. Authentication above layer-2 works for any link technology (e.g., home, cable, cellular, office). 2. Authentication at the application layer (as is proposed for BURP, for example), independent of IP address, eliminates the need to do separate authentication for a dual stack(IPv4, IPv6). Appreciate your comments. Regards, Subir "Bernard D. Aboba" wrote: > Out of curiousity, how does IP-layer auth work in a multi-protocol > situation? > > For example, if I'm running dual stack (IPv4, IPv6), do I now need two > authentications, one for each protocol? What if one auth succeeds and > another fails? In effect, the interface is down for one protocol and up > for another. How does this work? > > I think that while it's easy to advocate "doing it at the IP layer" it's > a lot harder to describe how this would work (and why this solution would > be better than a linklayer one). -- **************************************************************************** **** Subir Das Ofc: MCC 1D-210R Telcordia Technologies Tel: 973 829 4959 (Formerly Bellcore) Fax: 973 829 5888 445, South Street E-mail: subir@research.telcordia.com Morristown, NJ 07960-6438 **************************************************************************** **** From owner-dhcp-v4@bucknell.edu Thu Feb 1 10:37:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29486 for ; Thu, 1 Feb 2001 10:37:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11Fava19463; Thu, 1 Feb 2001 10:36:57 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11Faua21039 for ; Thu, 1 Feb 2001 10:36:56 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 10:36:40 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Thu, 1 Feb 2001 10:36:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Henry, Let me agree with you entirely! So, PPP provided us with a mechanism to trigger AAA at the Access Router....in the absence of PPP we need some alternative. Note! We only need a signalling protocol over the access link...AAA covers very comprehensively how the Access Router (or in fact its AAA client) communicates with the AAA server to provide the Access Router with the correct policy/configuration/firewall for the MN. Thanks George -----Original Message----- From: henry.haverinen@nokia.com [mailto:henry.haverinen@nokia.com] Sent: Wednesday, January 31, 2001 8:38 AM To: dhcp-v4@bucknell.edu; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Hi all, > > Can some one point out why existing protocols such as > Radius/COPS (with some > > modification) can not do the same. OR. What else is being > solved by BURP? (Or Diameter as Pat pointed out.) The reason why an AAA protocol such as Diameter or Radius cannot be used is that they are not designed to be used by visiting hosts but by an attendant on the visited network. The attendant is the device that visiting hosts contact in order to get access to the network. The attendant is typically a Diameter (or Radius) _client_ and it speaks Diameter with the AAA network. BURP is expected to be a network access authorization protocol between the visiting host and the attendant when PPP or Mobile IP cannot be used. Regards, Henry From owner-dhcp-v4@bucknell.edu Thu Feb 1 10:51:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29669 for ; Thu, 1 Feb 2001 10:51:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11FoNa29311; Thu, 1 Feb 2001 10:50:23 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11Fo6a03249 for ; Thu, 1 Feb 2001 10:50:07 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA11148; Thu, 1 Feb 2001 07:49:47 -0800 (PST) Message-Id: <4.1.20010201104446.00b5ea70@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 01 Feb 2001 10:49:10 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 10:36 AM 02/01/2001 -0500, George Tsirtsis wrote: >... >Note! We only need a signalling protocol over the access link...AAA covers >very comprehensively how the Access Router (or in fact its AAA client) >communicates with the AAA server to provide the Access Router with the >correct policy/configuration/firewall for the MN. This makes a lot of sense to me. It also fits well with Bernard's suggestion of using IEEE 802.1x. What is wrong with this? At 09:57 PM 01/26/2001 -0800, Bernard Aboba wrote: >... >I've also often wondered why it is that we need PPP in xDSL. The Ethernet >in the Last Mile (ELM) study group in IEEE is looking at DSL-based >Ethernet PHYs, so that you could use Ethernet as the link layer instead. >For this, IEEE 802.1X Network Port Authentication would be used for >access control. See: > >http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz > From owner-dhcp-v4@bucknell.edu Thu Feb 1 11:06:38 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29993 for ; Thu, 1 Feb 2001 11:06:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11G4Na16969; Thu, 1 Feb 2001 11:04:23 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11G4Ha26367 for ; Thu, 1 Feb 2001 11:04:18 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 11:04:01 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu, urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Thu, 1 Feb 2001 11:04:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Allow me to add one more.... * No packet (originated from the end node) goes through the Access Router until this mechanism completes successfully. Not sure about framing...I guess we will need to define transport for this mechanism...maybe an existing one can do the job but if not...we can always put it on top of DHCP as the draft in the subject indicates :-) George -----Original Message----- From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] Sent: Thursday, February 01, 2001 3:49 PM To: George Tsirtsis Cc: dhcp-v4@bucknell.edu; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt > Let me agree with you entirely! So, PPP provided us with a mechanism to > trigger AAA at the Access Router....in the absence of PPP we need some > alternative. Correct, and the requirements that I have are (in no particular order of importance): 1. Lightweight 2. Requires minimal (ideally no) link state (besides up/down) on the access router 3. Allows for frames to be interrupted, to allow high priority frames to take precedence 4. has an efficient framing mechanism 5. Has an authentication phase The question I have is whether a new framing format is in scope, or just the authentication mechanism? PatC From owner-dhcp-v6@bucknell.edu Thu Feb 1 18:04:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13971; Thu, 1 Feb 2001 18:04:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11MwFa23827; Thu, 1 Feb 2001 17:58:15 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11Mw8a29643 for ; Thu, 1 Feb 2001 17:58:08 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA00944 for ; Thu, 1 Feb 2001 17:57:51 -0500 (EST) Message-Id: <4.3.1.2.20010201174312.00afe930@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 01 Feb 2001 17:58:02 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: IA identifiers 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 the WG meeting in San Diego, we discussed how DHCP clients and servers can identify Identity Associations (IAs). The two proposals on the table are to use a DHCP Unique Identifier (DUID) or to use the interface identifier portion of a host's link-local address along with a prefix from the link to which the host is attached. In short summary, the difference between the two schemes is the assumptions about the global identity an IA. If we use a DUID to identify an IA, DHCP servers can assume that an IA with the same DUID that arrives from a new link (from a different link than it was originally associated with) is really the same IA, and the servers can take action on that assumption. If we use , a roaming IA cannot be identified. We have not yet fully defined how hosts might be able to generate a DUID that can be guaranteed to be unique among all DHCP clients. We have operational experience with DHCPv4 that assuming MAC addresses (e.g., from a NIC) are unique is a bad assumption, and that identifier clashes among DHCP clients in DHCPv4 has been a problem. We need to resolve this issue before the spec can go to WG last call. I want to kick off the discussion by giving the WG a chance to get the issues out on the table before we get to making a decision about which strategy to use. So, here are a couple of questions to open the discussion: * Does this message accurately summarize previous WG discussion on the issue? * Are there other strategies for IA identification that we should consider? * What are all of the effects of choosing one or the other (or some entirely different) mechanism for IA identification? - Ralph From owner-dhcp-v6@bucknell.edu Thu Feb 1 18:07:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14016; Thu, 1 Feb 2001 18:07:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11N4ea25456; Thu, 1 Feb 2001 18:04:40 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11N4Qa29553 for ; Thu, 1 Feb 2001 18:04:27 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA01616 for ; Thu, 1 Feb 2001 18:04:11 -0500 (EST) Message-Id: <4.3.1.2.20010201180058.00c32900@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 01 Feb 2001 18:04:22 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Control of DHCPv6 operational parameters 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 From the minutes of the San Diego meeting: * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. So, here's the start of the discussion: * Is it worthwhile to allow a DHCP server to control those parameters in a client? * How should a client react when rebooting because of power cycle or loss of link - revert to default parameters, use last known parameters, ??? * What should a client use as default values for all of the control parameters? - Ralph From owner-dhcp-v6@bucknell.edu Thu Feb 1 18:10:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14086; Thu, 1 Feb 2001 18:10:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11NAea28694; Thu, 1 Feb 2001 18:10:40 -0500 (EST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11NATa07807 for ; Thu, 1 Feb 2001 18:10:30 -0500 (EST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA21054 for ; Fri, 2 Feb 2001 08:10:28 +0900 (JST) To: DHCPv6 discussion list In-reply-to: rdroms's message of Thu, 01 Feb 2001 17:58:02 EST. <4.3.1.2.20010201174312.00afe930@funnel.cisco.com> X-Template-Reply-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IA identifiers From: itojun@ITOJUN.ORG Date: Fri, 02 Feb 2001 08:10:28 +0900 Message-ID: <21052.981069028@coconut.itojun.org> Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: itojun@itojun.org X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >At the WG meeting in San Diego, we discussed how DHCP clients and servers >can identify Identity Associations (IAs). The two proposals on the table >are to use a DHCP Unique Identifier (DUID) or to use the interface >identifier portion of a host's link-local address along with a prefix from >the link to which the host is attached. > >In short summary, the difference between the two schemes is the assumptions >about the global identity an IA. If we use a DUID to identify an IA, DHCP >servers can assume that an IA with the same DUID that arrives from a new >link (from a different link than it was originally associated with) is >really the same IA, and the servers can take action on that assumption. If >we use , a roaming IA cannot be identified. > >We have not yet fully defined how hosts might be able to generate a DUID >that can be guaranteed to be unique among all DHCP clients. We have >operational experience with DHCPv4 that assuming MAC addresses (e.g., from >a NIC) are unique is a bad assumption, and that identifier clashes among >DHCP clients in DHCPv4 has been a problem. sorry if I don't follow past discussions well. if there's no concrete algorithm for generating DUID, i think the discussions will not be useful... i'd suggest either (1) define DUID generation algorithm and then discuss between DUID and interface ID, (2) use inteface ID (i believe it so hard to define DUID with total global uniqueness - it is almost impossible, I think) itojun From owner-dhcp-v6@bucknell.edu Thu Feb 1 18:17:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14184; Thu, 1 Feb 2001 18:17:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11NGca17442; Thu, 1 Feb 2001 18:16:39 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11NGYa27116 for ; Thu, 1 Feb 2001 18:16:34 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 18:16:18 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036076EF@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Control of DHCPv6 operational parameters Date: Thu, 1 Feb 2001 18:16:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, et al: I'd like to suggest that we have the client use its own values for all of these parameters for now (either 'default' values specified in the draft or values configured on the client through some client specific method that override the 'defaults'). It is just simpler and should reduce the discussions. There's already plenty to resolve in getting this specification out and it would be nice to eliminate this for now. The one problem with defining this in the future is that clients may not use the parameters from a server. HOWEVER, I don't think that should be a major issue since a client will NEVER use a server's values until after it has at least communicated with the server. And, client policy might prohibit use of certain values (at least if they are outside of a specified range). The issue of the default values still exists. Perhaps with the next draft revision we will have a list of the parameters and can discuss their values in the conference call (2/15?). - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 01, 2001 6:04 PM To: DHCPv6 discussion list Subject: Control of DHCPv6 operational parameters From the minutes of the San Diego meeting: * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. So, here's the start of the discussion: * Is it worthwhile to allow a DHCP server to control those parameters in a client? * How should a client react when rebooting because of power cycle or loss of link - revert to default parameters, use last known parameters, ??? * What should a client use as default values for all of the control parameters? - Ralph From owner-dhcp-v6@bucknell.edu Thu Feb 1 18:19:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14221; Thu, 1 Feb 2001 18:19:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11NJXa24958; Thu, 1 Feb 2001 18:19:33 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11NIEa20274 for ; Thu, 1 Feb 2001 18:18:14 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 18:17:59 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036076F0@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: IA identifiers Date: Thu, 1 Feb 2001 18:17:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Wasn't Ted going to write up something about a technique to generate unique ids? It was to use communication with the server to have the server provide a DUID to the client (if the client didn't have another mechanism for providing one). [Sorry to put you on the spot Ted.] - Bernie -----Original Message----- From: itojun@itojun.org [mailto:itojun@itojun.org] Sent: Thursday, February 01, 2001 6:10 PM To: DHCPv6 discussion list Subject: Re: IA identifiers >At the WG meeting in San Diego, we discussed how DHCP clients and servers >can identify Identity Associations (IAs). The two proposals on the table >are to use a DHCP Unique Identifier (DUID) or to use the interface >identifier portion of a host's link-local address along with a prefix from >the link to which the host is attached. > >In short summary, the difference between the two schemes is the assumptions >about the global identity an IA. If we use a DUID to identify an IA, DHCP >servers can assume that an IA with the same DUID that arrives from a new >link (from a different link than it was originally associated with) is >really the same IA, and the servers can take action on that assumption. If >we use , a roaming IA cannot be identified. > >We have not yet fully defined how hosts might be able to generate a DUID >that can be guaranteed to be unique among all DHCP clients. We have >operational experience with DHCPv4 that assuming MAC addresses (e.g., from >a NIC) are unique is a bad assumption, and that identifier clashes among >DHCP clients in DHCPv4 has been a problem. sorry if I don't follow past discussions well. if there's no concrete algorithm for generating DUID, i think the discussions will not be useful... i'd suggest either (1) define DUID generation algorithm and then discuss between DUID and interface ID, (2) use inteface ID (i believe it so hard to define DUID with total global uniqueness - it is almost impossible, I think) itojun From owner-dhcp-v6@bucknell.edu Thu Feb 1 19:02:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15074; Thu, 1 Feb 2001 19:02:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f11NxGa23302; Thu, 1 Feb 2001 18:59:16 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f11Nx6a04091 for ; Thu, 1 Feb 2001 18:59:06 -0500 (EST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 15:21:32 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 15:22:17 -0800 (Pacific Standard Time) Received: from DF-MYDOCS.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 15:22:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Control of DHCPv6 operational parameters Date: Thu, 1 Feb 2001 15:21:53 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A681B6595@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Control of DHCPv6 operational parameters Thread-Index: AcCMpCQOV90vm7EYQW6RPQkYegY0lgAAN5/g From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 01 Feb 2001 23:22:06.0225 (UTC) FILETIME=[CA8F3810:01C08CA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f11Nx6a08064 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit I think the client should have a set of default parameters to start with that can be overridden from a server. If the client is not sure of what parameter to use, it should use the default parameters. Using last known good may not work in all the scenarios. It is not clear if one set of default values will suffice for all the scenarios. Is it advisable to let the implementation choose the defaults that can be overridden by the server? thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 01, 2001 3:04 PM To: DHCPv6 discussion list Subject: Control of DHCPv6 operational parameters From the minutes of the San Diego meeting: * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. So, here's the start of the discussion: * Is it worthwhile to allow a DHCP server to control those parameters in a client? * How should a client react when rebooting because of power cycle or loss of link - revert to default parameters, use last known parameters, ??? * What should a client use as default values for all of the control parameters? - Ralph From owner-dhcp-v6@bucknell.edu Fri Feb 2 00:57:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20839; Fri, 2 Feb 2001 00:57:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f125ssa06292; Fri, 2 Feb 2001 00:54:54 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f125sia00975 for ; Fri, 2 Feb 2001 00:54:44 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA23856 for ; Thu, 1 Feb 2001 21:54:42 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f125sSn11334 for ; Thu, 1 Feb 2001 21:54:28 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id VAA02415 for ; Thu, 1 Feb 2001 21:54:26 -0800 (PST) Message-Id: <4.3.1.2.20010202003916.00b40b60@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 02 Feb 2001 00:53:57 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Questions about Release message 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 There are some outstanding questions about Release messages in section 11.6.2 of the -16 DHCPv6 spec: What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? Can a client send an empty IA to release all addresses in the IA? If the IA becomes empty - all addresses are released - can the server discard any record of the IA? From owner-dhcp-v4@bucknell.edu Fri Feb 2 06:27:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06188 for ; Fri, 2 Feb 2001 06:27:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f12BMFa26425; Fri, 2 Feb 2001 06:22:15 -0500 (EST) Received: from blaze.hcltech.com ([203.199.199.225]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f12BMBa11505 for ; Fri, 2 Feb 2001 06:22:11 -0500 (EST) Received: from nahar.netlab.hcltech.com (nahar [192.168.201.35]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id RAA19599 for ; Fri, 2 Feb 2001 17:00:47 +0530 Message-Id: <5.0.2.1.0.20010202165543.00a12780@192.168.201.1> X-Sender: vknahar@192.168.201.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Feb 2001 16:57:22 +0530 To: DHCPv4 discussion list From: Virendra K Nahar Subject: client code testing Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_83272286==_.ALT" Reply-To: vknahar@netlab.hcltech.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --=====================_83272286==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed hi does any one has stubs to test DHCP client code .Pls suggest the ways as to how perform the client code testing. thanks nahar Virendra Nahar Member Technical Staff HCL Technologies Ltd Networking Systems Lab 51-JN Road Chennai -97 Ph-2334181 email:vknahar@netlab.hcltech.com --=====================_83272286==_.ALT Content-Type: text/html; charset="us-ascii" hi
does any one has stubs to test DHCP client code .Pls suggest the ways as to how perform the client code testing.

thanks
nahar

Virendra Nahar
Member Technical Staff
HCL Technologies Ltd
Networking Systems Lab
51-JN Road
Chennai -97
Ph-2334181
email:vknahar@netlab.hcltech.com --=====================_83272286==_.ALT-- From owner-dhcp-v4@bucknell.edu Fri Feb 2 12:34:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17309 for ; Fri, 2 Feb 2001 12:34:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f12HQca04778; Fri, 2 Feb 2001 12:26:38 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f12HQMa23187 for ; Fri, 2 Feb 2001 12:26:22 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19372; Fri, 2 Feb 2001 09:26:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA29327; Fri, 2 Feb 2001 09:26:08 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f12HQ6R617523; Fri, 2 Feb 2001 09:26:06 -0800 (PST) Date: Fri, 2 Feb 2001 09:25:57 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: aboba@internaut.com, DHCPv4 discussion list , urp@research.telcordia.com 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 > 1. Authentication above layer-2 works for any link technology (e.g., home, > cable, cellular, office). > > 2. Authentication at the application layer (as is proposed for BURP, for > example), independent of IP address, eliminates the need to do > separate authentication for a dual stack(IPv4, IPv6). I understand the above. But, in order for access control to be affective, doesn't access control have to be implemented at L2 (or L1)? Otherwise an unauthenticated entity can just spoof its IP address to be that of an already authenticated entity and gain access. If access control needs to be done at L2 (or L1) what are the benefits of having L3 or higher protocols for authentication? Erik From owner-dhcp-v4@bucknell.edu Sat Feb 3 03:14:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26496 for ; Sat, 3 Feb 2001 03:14:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1387qa22637; Sat, 3 Feb 2001 03:07:53 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1387ia26392 for ; Sat, 3 Feb 2001 03:07:44 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1382XR28936; Sat, 3 Feb 2001 00:02:33 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "DHCPv4 discussion list" , Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Sat, 3 Feb 2001 00:08:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >I understand the above. >But, in order for access control to be affective, doesn't access control >have to be implemented at L2 (or L1)? If access control is done at L3, then you would presumably need access control within every L3 protocol, or risk attack on the protocols for which there was no access control. Whereas if you did access control at L2 then it would apply to all L3 protocols. Also, one needs to be clear about *what* is being controlled -- in L2 access control, it is typically access to the port. Whereas with L3 access control, it is typically access by the host. The latter implies more state kept on the NAS. These would be strong arguments for L2 in a traditional multi-protocol environment (IPv4, AppleTalk, DECNET, IPX, NetBEUI, SNA, etc.) where device cost is an important concern. However, in an all-IP network (IPv4, IPv6), where devices can be much more capable than they were in the 90s, I'm not clear that the argument remains compelling. One can think of access control at each L3 as somewhat akin to negotiating both IPCP and IPv6CP within PPP. So the question that comes to mind is "what advantages does one gain by this approach?" For example, can access control be done better at L3 than at L2 due to facilities existing in IP or TCP? (e.g. fragmentation, reliable transport, etc.) And are any important L2 facilities lost as a result? (L2 negotiations) >Otherwise an unauthenticated entity can just spoof its IP address to be that >of an already authenticated entity and gain access. That's why authenticated DHCP isn't an access control mechanism ;) But the need to link BURP to DHCP is far from clear. From owner-dhcp-v4@bucknell.edu Mon Feb 5 04:59:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02789 for ; Mon, 5 Feb 2001 04:59:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f159pja32241; Mon, 5 Feb 2001 04:51:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f159pVa31563 for ; Mon, 5 Feb 2001 04:51:32 -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 BAA14806; Mon, 5 Feb 2001 01:51:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id BAA15358; Mon, 5 Feb 2001 01:51:29 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f159pQR115182; Mon, 5 Feb 2001 01:51:27 -0800 (PST) Date: Sun, 4 Feb 2001 17:16:36 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu, urp@research.telcordia.com In-Reply-To: "Your message with ID" 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 > Let me agree with you entirely! So, PPP provided us with a mechanism to > trigger AAA at the Access Router....in the absence of PPP we need some > alternative. George, Presumbly the protocol should work when there are multiple access routers on the link. I don't see why we need to cripple e.g. an Ethernet to only have one router; allowing multiple provides more efficient routing but more importantly some redundancy. Erik From owner-dhcp-v4@bucknell.edu Mon Feb 5 05:12:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02885 for ; Mon, 5 Feb 2001 05:12:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15AApa30227; Mon, 5 Feb 2001 05:10:51 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15AAja26134 for ; Mon, 5 Feb 2001 05:10:45 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 05:10:29 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu, urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 5 Feb 2001 05:10:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Erik, Sure, it would be great to build a protocol that can work with multiple routers on the link. Again, my initial focus was on point to point links but shared mediums should also be looked at. PPP was point to point only and thus could maintain state...if we design a new protocol we might try to make it less stateful and/or find a way to destribute the result of the AAA function (firewall settings etc). thanks George -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Monday, February 05, 2001 1:17 AM To: George Tsirtsis Cc: dhcp-v4@bucknell.edu; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt > Let me agree with you entirely! So, PPP provided us with a mechanism to > trigger AAA at the Access Router....in the absence of PPP we need some > alternative. George, Presumbly the protocol should work when there are multiple access routers on the link. I don't see why we need to cripple e.g. an Ethernet to only have one router; allowing multiple provides more efficient routing but more importantly some redundancy. Erik From owner-dhcp-v4@bucknell.edu Mon Feb 5 11:47:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11572 for ; Mon, 5 Feb 2001 11:47:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15Gdta09613; Mon, 5 Feb 2001 11:39:55 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15Gdga32107 for ; Mon, 5 Feb 2001 11:39:43 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 11:39:19 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: DHCPv4 discussion list , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 5 Feb 2001 11:39:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Bernard, I just had a look at draft-congdon-radius-8021x-09.txt and I think I know understand your comments in relation to the relevance to this proposal. The congdon draft provides a vehicle for authenticating nodes that use 802 types of link layers. Even if we assume the above L2 approach satisfies the urp requirements of these layers, what should we do about the non-802 L2s? -One approach is to say that L2s are either shared in which case probably 802 based or point to point in which case PPP should be used. I would disagree with both of the above assumptions. -Another approach would say that non-802 L2s should also have their own 'congdon' like authentication mechanisms, which I think would be difficult and is at least as difficult with the idea of having per L3 authentication mechanisms -Alternatively, a L3 mechanism may need to be invented that can run over any L2 and ensure authentication per L3...as you suggest below IPCP and IPCPv6 like...which is I think what I support. Regards George P.S.: note that whether the L3 authentication mechanisms should ride on DHCP messages or not is beside the point here...my related proposal was born in isolation to BURP, trying to solve a specific engineering problem. If we find a generic protocol to do this I am happy to drop the DHCP proposal....but not just yet :-) -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Saturday, February 03, 2001 8:08 AM To: Erik Nordmark; Subir Das Cc: DHCPv4 discussion list; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt >I understand the above. >But, in order for access control to be affective, doesn't access control >have to be implemented at L2 (or L1)? If access control is done at L3, then you would presumably need access control within every L3 protocol, or risk attack on the protocols for which there was no access control. Whereas if you did access control at L2 then it would apply to all L3 protocols. Also, one needs to be clear about *what* is being controlled -- in L2 access control, it is typically access to the port. Whereas with L3 access control, it is typically access by the host. The latter implies more state kept on the NAS. These would be strong arguments for L2 in a traditional multi-protocol environment (IPv4, AppleTalk, DECNET, IPX, NetBEUI, SNA, etc.) where device cost is an important concern. However, in an all-IP network (IPv4, IPv6), where devices can be much more capable than they were in the 90s, I'm not clear that the argument remains compelling. One can think of access control at each L3 as somewhat akin to negotiating both IPCP and IPv6CP within PPP. So the question that comes to mind is "what advantages does one gain by this approach?" For example, can access control be done better at L3 than at L2 due to facilities existing in IP or TCP? (e.g. fragmentation, reliable transport, etc.) And are any important L2 facilities lost as a result? (L2 negotiations) >Otherwise an unauthenticated entity can just spoof its IP address to be that >of an already authenticated entity and gain access. That's why authenticated DHCP isn't an access control mechanism ;) But the need to link BURP to DHCP is far from clear. From owner-dhcp-v6@bucknell.edu Mon Feb 5 14:02:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14593; Mon, 5 Feb 2001 14:02:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15IxKa22137; Mon, 5 Feb 2001 13:59:20 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15Ix8a30225 for ; Mon, 5 Feb 2001 13:59:08 -0500 (EST) Received: from rdroms-nt.cisco.com (dhcp-128-107-134-86.cisco.com [128.107.134.86]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24947 for ; Mon, 5 Feb 2001 13:58:40 -0500 (EST) Message-Id: <4.3.1.2.20010205091104.00b31520@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 05 Feb 2001 11:15:52 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Issues regarding server-inituated client configuration (Reconfigure-init) from San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This was originally the first part of a longer message. I split that long message into two shorter messages to encourage prompt response to either or (preferably!) both messages. Please take a quick look at this first message and respond with comments (or with an ACK if you think the list of issues is accurate and complete). In the discussion about reconfiguration at the San Diego IETF, the following issues were raised: * Multicast reconfiguration would be a good thing * Multicast reconfiguration is required in the case where the server does not have a complete list of clients; e.g., if the server has been delivering configuration information but not assigning addresses and has not recorded a list of clients that have contacted the server * Multicast reconfiguration requires additional consideration of scaling issues to avoid server failure in the event of multiple simultaneous client responses * Clients must be made resilient against the receipt of multiple copies of a Reconfigure-init message; e.g. because there are mulitple relay agents on the link or because the Reconfigure-init message was duplicated in transit * There must be an authentication mechanism that is compatible with both unicast and multicast to avoid denial of service attacks. Is this a complete list of issues raised in San Diego? (I'm not sure we raised authentication in San Diego, but the problem has to be solved...) - Ralph From owner-dhcp-v6@bucknell.edu Mon Feb 5 14:03:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14685; Mon, 5 Feb 2001 14:03:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15J0Ba10047; Mon, 5 Feb 2001 14:00:12 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15Ixra00108 for ; Mon, 5 Feb 2001 13:59:53 -0500 (EST) Received: from rdroms-nt.cisco.com (dhcp-128-107-134-86.cisco.com [128.107.134.86]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA25136; Mon, 5 Feb 2001 13:59:37 -0500 (EST) Message-Id: <4.3.1.2.20010205114836.00b12780@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 05 Feb 2001 11:57:03 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Authentication of multicast Reconfigure-init messages Cc: waa@cs.umd.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 I don't know how to authenticate multicast DHCPv6 Reconfigure-init messages. We can use DHCPv4-style authentication - with a separate secret key for each client - for unicast Reconfigure-init messages. However, because the multicast Reconfigure-init will be received by multiple clients, we can't use a client-specific shared key. And, if we use a single, shared server-specific key, any client configured with the key can masquerade as an authorized server. I would guess we could use a public key encryption mechanism, where the authorized servers hold a private key and use it to generate an authenticator. The clients can then authenticate the servers using the associated public key. This scheme would assume that the servers are trusted and the private key can be shared among those servers. Anyone care to jump in and tell me how to use DHCPv4-style authentication, flesh out this public key idea or come up with some entirely different strategy? - Ralph From owner-dhcp-v4@bucknell.edu Mon Feb 5 15:29:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16834 for ; Mon, 5 Feb 2001 15:29:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15KMHa09912; Mon, 5 Feb 2001 15:22:17 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15KLwa04705 for ; Mon, 5 Feb 2001 15:21:59 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f15KG2R02837; Mon, 5 Feb 2001 12:16:02 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Cc: Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 5 Feb 2001 12:21:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >One approach is to say that L2s are either shared in which case probably >802 based or point to point in which case PPP should be used. I would >disagree with both of the above assumptions. Just curious about the problem space. Are we talking about access control for L2s like ATM, Frame Relay, or wireless WAN? Note that with 802.11 and Ethernet over DSL, 802 is being used as the link layer for wireless LANs and xDSL. I'm also curious as to the type of access control that you want. Is it per-station access control? Per port access control? For example, on a shared medium do *all* hosts need to authenticate? Or is the medium assumed to be point to point? From owner-dhcp-v4@bucknell.edu Mon Feb 5 17:08:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18833 for ; Mon, 5 Feb 2001 17:08:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f15M11a06795; Mon, 5 Feb 2001 17:01:01 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f15M0ua32543 for ; Mon, 5 Feb 2001 17:00:58 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1L64LCAK>; Mon, 5 Feb 2001 17:00:39 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 5 Feb 2001 17:00:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, February 05, 2001 8:22 PM To: G.Tsirtsis@flarion.com; DHCPv4 discussion list Cc: urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt >One approach is to say that L2s are either shared in which case probably >802 based or point to point in which case PPP should be used. I would >disagree with both of the above assumptions. Just curious about the problem space. Are we talking about access control for L2s like ATM, Frame Relay, or wireless WAN? GT> All of the above and more...I was thinking about a generic L3 access mechanism... Note that with 802.11 and Ethernet over DSL, 802 is being used as the link layer for wireless LANs and xDSL. GT> I learned that recently...still, I am sure there are and will be non-802 L2s? I'm also curious as to the type of access control that you want. Is it per-station access control? Per port access control? For example, on a shared medium do *all* hosts need to authenticate? Or is the medium assumed to be point to point? GT> I was thinking about per host access control for both point to point and shared mediums... Then again you reply with questions and we can keep going like that for ever :-) just joking...I am just trying to understand if you think there is nothing missing in this space or just that what is missing is marginal and thus not worth bothering about. Regards George From owner-dhcp-v4@bucknell.edu Mon Feb 5 19:33:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21280 for ; Mon, 5 Feb 2001 19:33:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f160POa20924; Mon, 5 Feb 2001 19:25:24 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f160P7a18840 for ; Mon, 5 Feb 2001 19:25:07 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f160JaO14978; Mon, 5 Feb 2001 19:19:37 -0500 (EST) Received: from research.telcordia.com (mmc-11-as5200-d27.cc.telcordia.com [128.96.11.27]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id TAA21586; Mon, 5 Feb 2001 19:19:34 -0500 (EST) Message-ID: <3A7F448E.4E97EA4B@research.telcordia.com> Date: Mon, 05 Feb 2001 19:25:50 -0500 From: Subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list , aboba@internaut.com, urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: subir@research.telcordia.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > 1. Authentication above layer-2 works for any link technology (e.g., home, > > cable, cellular, office). > > > > 2. Authentication at the application layer (as is proposed for BURP, for > > example), independent of IP address, eliminates the need to do > > separate authentication for a dual stack(IPv4, IPv6). > > I understand the above. > But, in order for access control to be affective, doesn't access control > have to be implemented at L2 (or L1)? > Otherwise an unauthenticated entity can just spoof its IP address to be that > of an already authenticated entity and gain access. I agree, but we are trying to segregate the user to network registration from access control. Moreover, the proposal is not to build an IP-layer access control protocol. I think, access control via firewall/ policing at the access router is a policy or architectural issue which is beyond the scope of BURP. In a nutshell, what we want to achieve is a Local Security Association (LSA) between the user and the network when an user enters into a visited network. However, the generated LSA between user and network can be used to help with access control either above or below the IP layer. > > If access control needs to be done at L2 (or L1) what are the benefits of > having L3 or higher protocols for authentication? As an example, Mobile IP clients need a L3 authentication even if there exists an authentication at L2. Similarly, many IETF protocols have their own (either in built or extended) end-client (user-node) that interacts with AAA infrastructure. But we need something when those protocols are absent or not required. A generic user registration protocol at the application layer may help other protocols to use the same LSA for authentication without extending individual protocol to work with AAA infrastructure. Regards, Subir From owner-dhcp-v4@bucknell.edu Mon Feb 5 19:33:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21291 for ; Mon, 5 Feb 2001 19:33:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f160SRa28834; Mon, 5 Feb 2001 19:28:27 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f160RFa14956 for ; Mon, 5 Feb 2001 19:27:15 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f160QwO15351; Mon, 5 Feb 2001 19:26:58 -0500 (EST) Received: from research.telcordia.com (mmc-11-as5200-d27.cc.telcordia.com [128.96.11.27]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id TAA22163; Mon, 5 Feb 2001 19:26:55 -0500 (EST) Message-ID: <3A7F4647.3DE34627@research.telcordia.com> Date: Mon, 05 Feb 2001 19:33:11 -0500 From: Subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: Erik Nordmark , DHCPv4 discussion list , urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: subir@research.telcordia.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > >I understand the above. > >But, in order for access control to be affective, doesn't access control > >have to be implemented at L2 (or L1)? > > If access control is done at L3, then you would presumably need > access control within every L3 protocol, or risk attack on the protocols > for which there was no access control. Whereas if you did access control > at L2 then it would apply to all L3 protocols. My understanding is if we do it at the application layer and create a Local Security Association (LSA), then network can make use of that LSA for other L3 protocol if it is necessary. Am I missing something? > > Also, one needs to be clear about *what* is being controlled -- in > L2 access control, it is typically access to the port. Whereas with > L3 access control, it is typically access by the host. The latter > implies more state kept on the NAS. > > These would be strong arguments for L2 in a traditional multi-protocol > environment (IPv4, AppleTalk, DECNET, IPX, NetBEUI, SNA, etc.) where > device cost is an important concern. I agree. > > > However, in an all-IP network (IPv4, IPv6), where devices can be > much more capable than they were in the 90s, I'm not clear that the > argument remains compelling. One can think of access control at each L3 as > somewhat akin to negotiating both IPCP and IPv6CP within PPP. > > So the question that comes to mind is "what advantages does one > gain by this approach?" For example, can access control be done better > at L3 than at L2 due to facilities existing in IP or TCP? (e.g. > fragmentation, > reliable transport, etc.) And are any important L2 facilities lost as > a result? (L2 negotiations). We say nothing about access control. Traditionally, L2 or L3 protocols have their own schemes and they never merged to a common platform so far. Is it that IETF has not paid much attention to lower layers or it is beyond its scope? On the other hand, in the real world there will always be multiple solutions from many standard bodies. > > > >Otherwise an unauthenticated entity can just spoof its IP address to be > that > >of an already authenticated entity and gain access. > > That's why authenticated DHCP isn't an access control mechanism ;) This is my understanding too. > But the need to link BURP to DHCP is far from clear. Is it necessary to link BURP to DHCP while we have multiple approaches (IPv4 autoconfiguration, IPv6 stateless autocnfiguration) to configure a host in absence of DHCP? Regards, Subir From owner-dhcp-v4@bucknell.edu Mon Feb 5 19:58:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21466 for ; Mon, 5 Feb 2001 19:58:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f160uoa28504; Mon, 5 Feb 2001 19:56:50 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f160uka29142 for ; Mon, 5 Feb 2001 19:56:46 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f160pFR17928; Mon, 5 Feb 2001 16:51:15 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Cc: Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 5 Feb 2001 16:57:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >I am just trying to understand if you think there is >nothing missing in this space or just that what is missing >is marginal and thus not worth bothering about. Overall, I think that the major determinant of whether there is "something missing" will be cost. As I'll describe, there are situations in which layer 3 access control can be implemented at relatively low incremental cost, and there are circumstances where this might be too expensive. It's hard to make an overall judgement -- since it's a pretty big problem space. For example, there might be demand for access control in ATM, Frame Relay, Wireless WAN. There's quite a bit of high priced equipment in these areas, so layer 3 access control might be fine. I'm just not familiar with that part of the world however, so perhaps someone else can comment. There might also be cases in which layer 3-4 access control might exhibit better efficiency (e.g. authentication requiring certificate chain exchanges). Again, I haven't had much hands-on experience with deployments of such technology so I can't say how bad existing solutions perform. I will say that I've been attending the IEEE 802 Ethernet Last Mile WG, and find their arguments for Ethernet over xDSL compelling. Basically, they believe they can dramatically cut the cost of xDSL equipment by moving to an Ethernet link layer, cutting out ATM and PPP. In this kind of scenario the CPE and Backend are both Ethernet switches. The CPEs typically have minimal L3 functionality (maybe just SNMP & syslog support, perhaps RADIUS, Web and telnet) and are only capable of handling L2 operations at wire speed. The CPE typically functions as a bridge which typically will not have L3 filtering capabilities, and to maintain a small CAM size, access control is done at the port level rather than host level. For this kind of device, doing L3 access control could drive up the cost, particularly if L3 filtering were required to operate at wire speed. The backends, being more expensive, typically have more hardware and smarts (e.g. DWDM interfaces, BGP, etc.) So adding L3 access control probably wouldn't be as big an issue on the backend. 802.1X was optimized for this environment, since it can be implemented on a purely L2 device, provides only authentication and doesn't require any encapsulation or L3 filtering that might sap performance. Thus, it can perform at speeds of 10+ Gbps. Similarly, use of 802.1X for 802.11 seems reasonable since 802.11 access points are relatively low priced devices (even enterprise access points only fetch $700 - $1000) with modest processing capabilities. From owner-dhcp-v4@bucknell.edu Tue Feb 6 05:17:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10573 for ; Tue, 6 Feb 2001 05:17:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16AEga12890; Tue, 6 Feb 2001 05:14:42 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16AEea20614 for ; Tue, 6 Feb 2001 05:14:40 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1TC0>; Tue, 6 Feb 2001 05:14:24 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: aboba@internaut.com, urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Tue, 6 Feb 2001 05:14:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Subir, Now I am getting confused. You want "network registration" but not "access control"...what does that mean? So you want to "register" to what? And if someone fails to "register" what does it happen? Don't you refuse "access"? and thus do access control? Maybe it would help if you could explain what the LSA is for. What happens when a node/user does not have an LSA and how you police the LSA. Thanks George -----Original Message----- From: Subir Das [mailto:subir@research.telcordia.com] Sent: Tuesday, February 06, 2001 12:26 AM To: DHCPv4 discussion list Cc: DHCPv4 discussion list; aboba@internaut.com; urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt Erik Nordmark wrote: > > 1. Authentication above layer-2 works for any link technology (e.g., home, > > cable, cellular, office). > > > > 2. Authentication at the application layer (as is proposed for BURP, for > > example), independent of IP address, eliminates the need to do > > separate authentication for a dual stack(IPv4, IPv6). > > I understand the above. > But, in order for access control to be affective, doesn't access control > have to be implemented at L2 (or L1)? > Otherwise an unauthenticated entity can just spoof its IP address to be that > of an already authenticated entity and gain access. I agree, but we are trying to segregate the user to network registration from access control. Moreover, the proposal is not to build an IP-layer access control protocol. I think, access control via firewall/ policing at the access router is a policy or architectural issue which is beyond the scope of BURP. In a nutshell, what we want to achieve is a Local Security Association (LSA) between the user and the network when an user enters into a visited network. However, the generated LSA between user and network can be used to help with access control either above or below the IP layer. > > If access control needs to be done at L2 (or L1) what are the benefits of > having L3 or higher protocols for authentication? As an example, Mobile IP clients need a L3 authentication even if there exists an authentication at L2. Similarly, many IETF protocols have their own (either in built or extended) end-client (user-node) that interacts with AAA infrastructure. But we need something when those protocols are absent or not required. A generic user registration protocol at the application layer may help other protocols to use the same LSA for authentication without extending individual protocol to work with AAA infrastructure. Regards, Subir From owner-dhcp-v4@bucknell.edu Tue Feb 6 05:24:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10574 for ; Tue, 6 Feb 2001 05:17:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16AABa32240; Tue, 6 Feb 2001 05:10:12 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16AA1a02903 for ; Tue, 6 Feb 2001 05:10:02 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1TC7>; Tue, 6 Feb 2001 05:09:44 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: Erik Nordmark , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Tue, 6 Feb 2001 05:09:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Subir Das [mailto:subir@research.telcordia.com] Sent: Tuesday, February 06, 2001 12:33 AM To: DHCPv4 discussion list Cc: Erik Nordmark; DHCPv4 discussion list; urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt ... > > > >Otherwise an unauthenticated entity can just spoof its IP address to be > that > >of an already authenticated entity and gain access. > > That's why authenticated DHCP isn't an access control mechanism ;) This is my understanding too. GT> Lets get this straight. If AAA is triggered at the DHCP RA as I suggest then an attacker would have to spoof IP AND MAC addresses...which I think is a bit harder....Furthermore, unless we get per packet/frame authentication anything can be spoofed...so while DHCP is not an access control mechanism today, it can certainly be made to be... > But the need to link BURP to DHCP is far from clear. Is it necessary to link BURP to DHCP while we have multiple approaches (IPv4 autoconfiguration, IPv6 stateless autocnfiguration) to configure a host in absence of DHCP? GT> Now this is a good point, and that is why I am in favor of a generic (non-DHCP, non-802, non-anything) L3 access control/authentication mechanism if it can be made to work despite my own proposal regarding DHCP. George From owner-dhcp-v4@bucknell.edu Tue Feb 6 06:02:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10865 for ; Tue, 6 Feb 2001 06:02:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16Au7a04612; Tue, 6 Feb 2001 05:56:07 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16Atva28181 for ; Tue, 6 Feb 2001 05:55:57 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1TDK>; Tue, 6 Feb 2001 05:55:37 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Tue, 6 Feb 2001 05:55:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernard, So it seams we are in agreement with respect to the cost of IP over PPP over X which is also my main reason for looking for an alternative....the question is as follows: - Is per port access control enough? If not, how do we do per host/user access control in the absence of PPP? - Is the 802.X applicable enough to cover all cases? If not, what do we do about non-802 links, in the absence of PPP? - If the answer to the above questions is 'No' then what are the L3/L4 alternatives? Do we need to extend and existing protocol or do we need to built a new one? Is this a fair summary of what this BOF is all about? Thanks George -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, February 06, 2001 12:57 AM To: G.Tsirtsis@flarion.com; DHCPv4 discussion list Cc: urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt >I am just trying to understand if you think there is >nothing missing in this space or just that what is missing >is marginal and thus not worth bothering about. Overall, I think that the major determinant of whether there is "something missing" will be cost. As I'll describe, there are situations in which layer 3 access control can be implemented at relatively low incremental cost, and there are circumstances where this might be too expensive. It's hard to make an overall judgement -- since it's a pretty big problem space. For example, there might be demand for access control in ATM, Frame Relay, Wireless WAN. There's quite a bit of high priced equipment in these areas, so layer 3 access control might be fine. I'm just not familiar with that part of the world however, so perhaps someone else can comment. There might also be cases in which layer 3-4 access control might exhibit better efficiency (e.g. authentication requiring certificate chain exchanges). Again, I haven't had much hands-on experience with deployments of such technology so I can't say how bad existing solutions perform. I will say that I've been attending the IEEE 802 Ethernet Last Mile WG, and find their arguments for Ethernet over xDSL compelling. Basically, they believe they can dramatically cut the cost of xDSL equipment by moving to an Ethernet link layer, cutting out ATM and PPP. In this kind of scenario the CPE and Backend are both Ethernet switches. The CPEs typically have minimal L3 functionality (maybe just SNMP & syslog support, perhaps RADIUS, Web and telnet) and are only capable of handling L2 operations at wire speed. The CPE typically functions as a bridge which typically will not have L3 filtering capabilities, and to maintain a small CAM size, access control is done at the port level rather than host level. For this kind of device, doing L3 access control could drive up the cost, particularly if L3 filtering were required to operate at wire speed. The backends, being more expensive, typically have more hardware and smarts (e.g. DWDM interfaces, BGP, etc.) So adding L3 access control probably wouldn't be as big an issue on the backend. 802.1X was optimized for this environment, since it can be implemented on a purely L2 device, provides only authentication and doesn't require any encapsulation or L3 filtering that might sap performance. Thus, it can perform at speeds of 10+ Gbps. Similarly, use of 802.1X for 802.11 seems reasonable since 802.11 access points are relatively low priced devices (even enterprise access points only fetch $700 - $1000) with modest processing capabilities. From owner-dhcp-v4@bucknell.edu Tue Feb 6 07:31:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11488 for ; Tue, 6 Feb 2001 07:31:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16CQIa04533; Tue, 6 Feb 2001 07:26:18 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16CQBa28173 for ; Tue, 6 Feb 2001 07:26:11 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id EAA32248; Tue, 6 Feb 2001 04:26:02 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00239; Tue, 6 Feb 01 05:02:02 -0800 Date: Tue, 6 Feb 2001 05:02:02 -0800 (GMT-0800) From: "Bernard D. Aboba" To: DHCPv4 discussion list Cc: DHCPv4 discussion list , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Tue, 6 Feb 2001, George Tsirtsis wrote: > > Bernard, > > So it seams we are in agreement with respect to the cost of IP over PPP over > X which is also my main reason for looking for an alternative....the > question is as follows: > > - Is per port access control enough? If not, how do we do per host/user > access control in the absence of PPP? > - Is the 802.X applicable enough to cover all cases? If not, what do we do > about non-802 links, in the absence of PPP? > - If the answer to the above questions is 'No' then what are the L3/L4 > alternatives? Do we need to extend and existing protocol or do we need to > built a new one? > > Is this a fair summary of what this BOF is all about? > > Thanks > George > Yes, I think those are a reasonable set of questions to explore. From owner-dhcp-v4@bucknell.edu Tue Feb 6 08:22:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13020 for ; Tue, 6 Feb 2001 08:22:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16DGna25663; Tue, 6 Feb 2001 08:16:49 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16DGVa28591 for ; Tue, 6 Feb 2001 08:16:32 -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 IAA12774; Tue, 6 Feb 2001 08:16:32 -0500 (EST) Message-Id: <200102061316.IAA12774@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-agentoptions-device-class-01.txt Date: Tue, 06 Feb 2001 08:16:31 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: scoya@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 : Addition of Device Class to Agent Options Author(s) : D. Jones, R. Woundy Filename : draft-ietf-dhc-agentoptions-device-class-01.txt Pages : 4 Date : 05-Feb-01 This document proposes a new sub-option to the DHCP Relay Information Agent Option. This new sub-option is for use with DOCSIS cable modems and describes a 'device class' to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signalling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-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-agentoptions-device-class-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-agentoptions-device-class-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: <20010205130720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentoptions-device-class-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentoptions-device-class-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010205130720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Tue Feb 6 13:21:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26683; Tue, 6 Feb 2001 13:21:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f16IHSa00036; Tue, 6 Feb 2001 13:17:28 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f16IHEa13527 for ; Tue, 6 Feb 2001 13:17:15 -0500 (EST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 6 Feb 2001 09:33:39 -0800 Received: from DF-MYDOCS.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 6 Feb 2001 09:34:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0 content-class: urn:content-classes:message Subject: RE: Authentication of multicast Reconfigure-init messages MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 6 Feb 2001 09:34:28 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A681B65A3@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Authentication of multicast Reconfigure-init messages Thread-Index: AcCPpecsfoowy4V6RCqIKRzOoA2DIQAvHOag From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 06 Feb 2001 17:34:29.0241 (UTC) FILETIME=[0EE4C690:01C09063] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f16IHFa02016 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit We ( Microsoft ) has been looking at this problem. I think a good solution is one where a client can authenticate the server. This avoids a) rogue dhcp servers cropping up in the network. ( intended or by accident ) b) the client can avoid the problem of getting invalid configuration info. However the problem here is that we want to minimize client configuration before bootstrap. The question is how can we use DHCP as a bootstrap protocol without using additional mechanism to configure the client at boot. May be L-2 authentication protocols can be used in some way to do this? thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 05, 2001 8:57 AM To: DHCPv6 discussion list Cc: waa@cs.umd.edu Subject: Authentication of multicast Reconfigure-init messages I don't know how to authenticate multicast DHCPv6 Reconfigure-init messages. We can use DHCPv4-style authentication - with a separate secret key for each client - for unicast Reconfigure-init messages. However, because the multicast Reconfigure-init will be received by multiple clients, we can't use a client-specific shared key. And, if we use a single, shared server-specific key, any client configured with the key can masquerade as an authorized server. I would guess we could use a public key encryption mechanism, where the authorized servers hold a private key and use it to generate an authenticator. The clients can then authenticate the servers using the associated public key. This scheme would assume that the servers are trusted and the private key can be shared among those servers. Anyone care to jump in and tell me how to use DHCPv4-style authentication, flesh out this public key idea or come up with some entirely different strategy? - Ralph From owner-dhcp-v6@bucknell.edu Tue Feb 6 19:55:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05328; Tue, 6 Feb 2001 19:55:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f170lua04124; Tue, 6 Feb 2001 19:47:56 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f170lqa03095 for ; Tue, 6 Feb 2001 19:47:52 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f170lqU05926 for ; Tue, 6 Feb 2001 18:47:52 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f170lp218389 for ; Tue, 6 Feb 2001 18:47:51 -0600 (CST) Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt749 ; Tue Feb 06 18:47:51 2001 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Feb 2001 18:48:56 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69353531@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Issues regarding server-inituated client configuration (Recon figure-init) from San Diego Date: Tue, 6 Feb 2001 18:48:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0909F.C00D70C0" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0909F.C00D70C0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I think the list is accurate (I'm pretty sure the authentication issue also was raised). Could some of the multicast reconfiguration problems be solved by: 1) Allowing only link-layer multicasts to be processed (hence, off link requests aren't possible; relays must be used to transmit reconfiguration on a link - this does raise a security issue such that relays only accept messages from proper servers, but that should be possible to handle with IPsec for communications between relay and servers). 2) As there is probably no need to have clients 'immediately' reconfigure, having clients wait a random time interval before responding and making the range something like 60 to 600 seconds. Yes, this means clients will wait at least a minute before reconfiguring. (These values could easily be adjusted.) 3) If multiple reconfiguration requests are received, they are ignored until the client has acted on the first. (And, of course, duplicates are ignored as well.) Now, what this means is that even if some rogue system is sending multicast reconfigure events, it can't generate a large amount of traffic, since: - Sending more often than every 60 seconds is meaningless (these are ignored by all clients). - Sending at that rate, only impacts a very small percentage of the clients (as, on average, half the clients will have acted within 360 seconds) Thus, very little traffic can be generated. Sure, clients might unnecessarily reconfigure, but that doesn't generate a lot of traffic (on average, each client will send 10 reconfigures per hour worst case). I guess if you do put thousands of clients on a single 'lan', you can generate a bunch of traffic. But, that network layout is very uncommon and not very effective anyway. One problem the above doesn't solve is if there are many servers generating the multicast reconfigure requests (since my assumption was the behavior was per server, not for all servers). Note: If faster reconfiguration times are desired, unicast messages would be used (it won't get all the systems, but at least those the server knows about). - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 05, 2001 11:16 AM To: DHCPv6 discussion list Subject: Issues regarding server-inituated client configuration (Reconfigure-init) from San Diego This was originally the first part of a longer message. I split that long message into two shorter messages to encourage prompt response to either or (preferably!) both messages. Please take a quick look at this first message and respond with comments (or with an ACK if you think the list of issues is accurate and complete). In the discussion about reconfiguration at the San Diego IETF, the following issues were raised: * Multicast reconfiguration would be a good thing * Multicast reconfiguration is required in the case where the server does not have a complete list of clients; e.g., if the server has been delivering configuration information but not assigning addresses and has not recorded a list of clients that have contacted the server * Multicast reconfiguration requires additional consideration of scaling issues to avoid server failure in the event of multiple simultaneous client responses * Clients must be made resilient against the receipt of multiple copies of a Reconfigure-init message; e.g. because there are mulitple relay agents on the link or because the Reconfigure-init message was duplicated in transit * There must be an authentication mechanism that is compatible with both unicast and multicast to avoid denial of service attacks. Is this a complete list of issues raised in San Diego? (I'm not sure we raised authentication in San Diego, but the problem has to be solved...) - Ralph ------_=_NextPart_001_01C0909F.C00D70C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issues regarding server-inituated client configuration = (Reconfigure-init) from San Diego

Ralph:

I think the list is accurate (I'm pretty sure the = authentication issue also was raised).

Could some of the multicast reconfiguration problems = be solved by:
1) Allowing only link-layer multicasts to be = processed (hence, off link requests aren't possible; relays must be = used to transmit reconfiguration on a link - this does raise a security = issue such that relays only accept messages from proper servers, but = that should be possible to handle with IPsec for communications between = relay and servers).

2) As there is probably no need to have clients = 'immediately' reconfigure, having clients wait a random time interval = before responding and making the range something like 60 to 600 = seconds. Yes, this means clients will wait at least a minute before = reconfiguring. (These values could easily be adjusted.)

3) If multiple reconfiguration requests are received, = they are ignored until the client has acted on the first. (And, of = course, duplicates are ignored as well.)

Now, what this means is that even if some rogue = system is sending multicast reconfigure events, it can't generate a = large amount of traffic, since:

- Sending more often than every 60 seconds is = meaningless (these are ignored by all clients).
- Sending at that rate, only impacts a very small = percentage of the clients (as, on average, half the clients will have = acted within 360 seconds)

Thus, very little traffic can be generated. Sure, = clients might unnecessarily reconfigure, but that doesn't generate a = lot of traffic (on average, each client will send 10 reconfigures per = hour worst case).

I guess if you do put thousands of clients on a = single 'lan', you can generate a bunch of traffic. But, that network = layout is very uncommon and not very effective anyway.

One problem the above doesn't solve is if there are = many servers generating the multicast reconfigure requests (since my = assumption was the behavior was per server, not for all = servers).

Note: If faster reconfiguration times are desired, = unicast messages would be used (it won't get all the systems, but at = least those the server knows about).

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 05, 2001 11:16 AM
To: DHCPv6 discussion list
Subject: Issues regarding server-inituated client = configuration
(Reconfigure-init) from San Diego


This was originally the first part of a longer = message.  I split that long
message into two shorter messages to encourage = prompt response to either or
(preferably!) both messages.  Please take a = quick look at this first
message and respond with comments (or with an ACK if = you think the list of
issues is accurate and complete).

In the discussion about reconfiguration at the San = Diego IETF, the
following issues were raised:

* Multicast reconfiguration would be a good = thing
* Multicast reconfiguration is required in the = case
   where the server does not have a = complete list of
   clients; e.g., if the server has = been
   delivering configuration information = but not
   assigning addresses and has not = recorded a list
   of clients that have contacted the = server
* Multicast reconfiguration requires = additional
   consideration of scaling issues to = avoid server
   failure in the event of multiple = simultaneous client
   responses
* Clients must be made resilient against the = receipt
   of multiple copies of a = Reconfigure-init message;
   e.g. because there are mulitple relay = agents on the
   link or because the Reconfigure-init = message
   was duplicated in transit
* There must be an authentication mechanism that = is
   compatible with both unicast and = multicast to avoid
   denial of service attacks.

Is this a complete list of issues raised in San = Diego?
(I'm not sure we raised authentication in San Diego, = but
the problem has to be solved...)
- Ralph

------_=_NextPart_001_01C0909F.C00D70C0-- From owner-dhcp-v6@bucknell.edu Tue Feb 6 20:14:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05582; Tue, 6 Feb 2001 20:14:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f171B4a16540; Tue, 6 Feb 2001 20:11:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f171Aqa24449 for ; Tue, 6 Feb 2001 20:10:52 -0500 (EST) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-115.cisco.com [10.19.238.116]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA19078 for ; Tue, 6 Feb 2001 20:10:31 -0500 (EST) Message-Id: <4.3.1.2.20010205092534.00b32300@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 06 Feb 2001 18:00:00 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: A proposal for DHCPv6 reconfiguration 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 Assuming I got the list of multicast reconfigure issues from San Diego right, here is a list of goals for server-initiated configuration: * When the server has a complete list of the clients to be reconfigured, the server will know reliably that each client has either been reconfigured exactly once or has not responded to the server's reconfiguration request * When the server does not have a complete list of clients, the server will have some assurance that each client has received at least one Reconfigure-init message * Wherever possible, redundant or gratuitous reconfiguration of clients will be avoided (even though reconfiguring more than once should not affect correct client operation) * Clients and servers must be able to authenticate Reconfigure-init messages, to avoid denial-of-service attacks Here's my proposal for server-initiated configuration, intended to meet the listed goals (except for multicast authentication, which I don't have a solution for): Reliable unicast transmission can be managed through the use of the transaction-id. The server includes a unique transaction ID in each unicast Reconfigure-init message. The client responds to the first Reconfigure-init message it receives, copying the transaction ID into the Reply message the client sends to the server, and ignores all subsequent Reconfigure-init messages with the same transaction ID. This behavior causes the server to ignore duplicate copies of a single Reconfigure-init message. If the server does not receive a Reply to the Reconfigure-init with a matching transaction ID, the server can try again by transmitting a new Reconfigure-init with a new transaction ID. The new transaction ID will cause the client to start the reconfiguration process again, in case the client did not receive earlier Reconfigure-init messages or the server did not receive the client's Reply. The delay before a server retries with a new Reconfigure-init, the number of times the server should retry before giving up and the server's action when it can't reach a client are TBD. As an aside, the behavior of a client that receives a Reconfigure-init while expecting an Advertise or Reply is not currently defined and is TBD. For reconfiguration using multicast, the server multicasts an initial message Reconfigure-init several times with the same transaction ID. The number of retransmissions and the delay between retransmissions is TBD. The client behavior is the same as in the unicast Reocnfigure-inti message: each client in the multicast group to which the Reconfigure-init message was transmitted responds to first message it receives (not necessarily the first message transmitted by the server) and ignores all other Reconfigure-init messages with the same transaction ID. The server maintains a list of those clients that have responded to the multicast Reconfigure-init message. After the multicast Reconfigure-init messages have been transmitted, the server reverts to unicast with new transaction ID for clients that have not responded respond. To reduce the number of simultaneous Replies recieved by a server, the server can include a delay parameter in the Reconfigure-init message. Clients then choose random time between 0 and the delay parameter to respond with a Reply message. From owner-dhcp-v6@bucknell.edu Tue Feb 6 20:39:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05873; Tue, 6 Feb 2001 20:39:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f170nla00336; Tue, 6 Feb 2001 19:49:47 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f170loa06432 for ; Tue, 6 Feb 2001 19:47:50 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f170lnU05899 for ; Tue, 6 Feb 2001 18:47:49 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f170lm218374 for ; Tue, 6 Feb 2001 18:47:48 -0600 (CST) Received: FROM eamrcnt751.exu.ericsson.se BY eamrcnt749 ; Tue Feb 06 18:47:48 2001 -0600 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Feb 2001 18:48:54 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69353530@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Authentication of multicast Reconfigure-init messages Date: Tue, 6 Feb 2001 18:48:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0909F.BE8B3D90" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0909F.BE8B3D90 Content-Type: text/plain; charset="iso-8859-1" Ralph: Another thought, what about just using IPsec?? It may be punting the problem, but why can't IPsec be used to handle this? The client and server should be able to define the appropriate security association needed (the client can add it when it has addresses assigned by the server). The PKI mechanism sounds good as a possibility as well. Wouldn't it simply require a new protocol for the DHCPv4-style authentication option to be defined? I'll leave it to PKI experts to define this. - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 05, 2001 11:57 AM To: DHCPv6 discussion list Cc: waa@cs.umd.edu Subject: Authentication of multicast Reconfigure-init messages I don't know how to authenticate multicast DHCPv6 Reconfigure-init messages. We can use DHCPv4-style authentication - with a separate secret key for each client - for unicast Reconfigure-init messages. However, because the multicast Reconfigure-init will be received by multiple clients, we can't use a client-specific shared key. And, if we use a single, shared server-specific key, any client configured with the key can masquerade as an authorized server. I would guess we could use a public key encryption mechanism, where the authorized servers hold a private key and use it to generate an authenticator. The clients can then authenticate the servers using the associated public key. This scheme would assume that the servers are trusted and the private key can be shared among those servers. Anyone care to jump in and tell me how to use DHCPv4-style authentication, flesh out this public key idea or come up with some entirely different strategy? - Ralph ------_=_NextPart_001_01C0909F.BE8B3D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Authentication of multicast Reconfigure-init = messages

Ralph:

Another thought, what about just using IPsec?? It may = be punting the problem, but why can't IPsec be used to handle this? The = client and server should be able to define the appropriate security = association needed (the client can add it when it  has addresses = assigned by the server).

The PKI mechanism sounds good as a possibility as = well. Wouldn't it simply require a new protocol for the DHCPv4-style = authentication option to be defined? I'll leave it to PKI experts to = define this.

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 05, 2001 11:57 AM
To: DHCPv6 discussion list
Cc: waa@cs.umd.edu
Subject: Authentication of multicast = Reconfigure-init messages


I don't know how to authenticate multicast DHCPv6 = Reconfigure-init
messages.  We can use DHCPv4-style = authentication - with a separate secret
key for each client - for unicast Reconfigure-init = messages.  However,
because the multicast Reconfigure-init will be = received by multiple
clients, we can't use a client-specific shared = key.  And, if we use a
single, shared server-specific key, any client = configured with the key can
masquerade as an authorized server.

I would guess we could use a public key encryption = mechanism, where the
authorized servers hold a private key and use it to = generate an
authenticator.  The clients can then = authenticate the servers using the
associated public key.  This scheme would = assume that the servers are
trusted and the private key can be shared among = those servers.

Anyone care to jump in and tell me how to use = DHCPv4-style authentication,
flesh out this public key idea or come up with some = entirely different
strategy?

- Ralph

------_=_NextPart_001_01C0909F.BE8B3D90-- From owner-dhcp-v4@bucknell.edu Wed Feb 7 06:57:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28138 for ; Wed, 7 Feb 2001 06:57:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17BoHa14596; Wed, 7 Feb 2001 06:50:17 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17Bo2a02360 for ; Wed, 7 Feb 2001 06:50:02 -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 DAA22274; Wed, 7 Feb 2001 03:49:58 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id DAA20992; Wed, 7 Feb 2001 03:49:58 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f17BnrR627429; Wed, 7 Feb 2001 03:49:53 -0800 (PST) Date: Wed, 7 Feb 2001 12:49:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: "'subir@research.telcordia.com'" , DHCPv4 discussion list , Erik Nordmark , urp@research.telcordia.com In-Reply-To: "Your message with ID" 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 > GT> Lets get this straight. If AAA is triggered at the DHCP RA as I suggest > then an attacker would have to spoof IP AND MAC addresses...which I think is > a bit harder....Furthermore, unless we get per packet/frame authentication > anything can be spoofed...so while DHCP is not an access control mechanism > today, it can certainly be made to be... 802.1X does per-port access control (great for switched Ethernets) and has some laguage (which I don't quite understand) about tying the access control to 802.11 per-station encryption with per-station keys. [The reason I don't quite understand it is because I thought 802.11 was using a single shared key for all the stations.] Thus 802.1X is an existence proof of an access control mechanism that is more fine grained than what you could ever do at L3 whether in a DHCP relay or somewhere else. Erik From owner-dhcp-v6@bucknell.edu Wed Feb 7 08:28:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28979; Wed, 7 Feb 2001 08:28:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17DN4a23136; Wed, 7 Feb 2001 08:23:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17DN3a16663 for ; Wed, 7 Feb 2001 08:23:04 -0500 (EST) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-247.cisco.com [10.19.238.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA25001 for ; Wed, 7 Feb 2001 08:22:46 -0500 (EST) Message-Id: <4.3.1.2.20010207081225.00c6f5e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 07 Feb 2001 08:22:59 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Input and teleconference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've only received three responses to my announcement of the next DHCPv6 teleconference. Because I don't yet have the next rev of the draft finished and because of that apparent lack of interest, I've decided to postpone the teleconference until I have a better sense of when the next rev will be finished. We need to have full WG participation in the discussion on a couple of issues raised at the San Diego WG meeting. I've started discussion on multicast reconfiguration and IA naming, but haven't seen many message in either thread. We also need to discuss how DHCPv6 will interact with anonymous addresses, which I will kick off in a separate message. I need this input before I can finish revving the draft. - Ralph From owner-dhcp-v6@bucknell.edu Wed Feb 7 08:47:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29381; Wed, 7 Feb 2001 08:47:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17DiDa11905; Wed, 7 Feb 2001 08:44:14 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17Dhxa27128 for ; Wed, 7 Feb 2001 08:43:59 -0500 (EST) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-247.cisco.com [10.19.238.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA26789 for ; Wed, 7 Feb 2001 08:43:42 -0500 (EST) Message-Id: <4.3.1.2.20010207083428.00b13de0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 07 Feb 2001 08:43:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Advertising prefixes 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 Prior to the -16 rev of the DHCPv6 draft, we decided to limit DHCPv6 to the assignment of addresses and eliminated the advertisement of prefixes. After thinking about some address management scenarios, it seems to me that it might be useful to combine DHCP and stateless autoconfiguration to provide host-specific prefix configuration without individual address management. My proposal is to allow a DHCP server to assign prefixes as well as addresses in an IA to a client. For example, the prefix might be carried in an IA as an address with all 0s in the low order bits (those bits not included in the prefix). The client would then apply stateless autoconfig to those DHCP-assigned prefixes. The client might also use the DHCP-assigned prefixes to generate anonymous addresses. DHCP assignment of prefixes would be useful in "managed access" networks, where not all of the prefixes assigned to a link are to be used by every client on that link. - Ralph From owner-dhcp-v4@bucknell.edu Wed Feb 7 12:26:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04371 for ; Wed, 7 Feb 2001 12:26:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17HJRa01883; Wed, 7 Feb 2001 12:19:27 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17HJMa04159 for ; Wed, 7 Feb 2001 12:19:22 -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 JAA29512; Wed, 7 Feb 2001 09:18:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20730; Wed, 7 Feb 2001 09:14:50 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f17H5oR670137; Wed, 7 Feb 2001 09:05:50 -0800 (PST) Date: Wed, 7 Feb 2001 18:05:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: "'Bernard Aboba'" , DHCPv4 discussion list , urp@research.telcordia.com In-Reply-To: "Your message with ID" 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 > So it seams we are in agreement with respect to the cost of IP over PPP over > X which is also my main reason for looking for an alternative....the > question is as follows: > > - Is per port access control enough? If not, how do we do per host/user > access control in the absence of PPP? > - Is the 802.X applicable enough to cover all cases? If not, what do we do > about non-802 links, in the absence of PPP? > - If the answer to the above questions is 'No' then what are the L3/L4 > alternatives? Do we need to extend and existing protocol or do we need to > built a new one? > > Is this a fair summary of what this BOF is all about? Yes, if there will be a BoF (which isn't clear yet) the most important thing is to answer the above level of questions. Erik From owner-dhcp-v6@bucknell.edu Wed Feb 7 14:55:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07676; Wed, 7 Feb 2001 14:55:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17Jmha09121; Wed, 7 Feb 2001 14:48:43 -0500 (EST) Received: from mail.local ([64.47.207.83]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17Jmaa32555 for ; Wed, 7 Feb 2001 14:48:36 -0500 (EST) Received: by MAIL with Internet Mail Service (5.5.2650.21) id <1F3BQ59Y>; Wed, 7 Feb 2001 11:48:18 -0800 Message-ID: From: "Anthony L. Sollars" To: DHCPv6 discussion list Subject: Changing the subnet that all machines exist on. Date: Wed, 7 Feb 2001 11:48:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello Everyone, I was wondering how I would, using DHCP, change all our dhcp using workstations to a class B subnet from a class C subnet. I currently have a windows NT domain with PDC & BDC. The DHCP server is on the PDC, plus each of these servers are statically adressed along with the mail and file servers. All oher machines get their IP info from DHCP. Right now the network is addressed with a class C subnet 10.0.0.x/255.255.255.0, which was instituted before I got here. I need to switch to a class B subnet, because we are running out of IP's. How can I do this using DHCP server, so clients automatically convert to the new subnet 10.1.x.x/255.255.0.0 ? Do I need to use some kind of DHCP relay server or multihomed server? Thanks in advance. Sincerely, Anthony L. Sollars System/Network Administrator tony@appliedinference.com Applied Inference Inc. 1756 114th Avenue SE Bellevue, Wa 98004 (425) 688-9921 From owner-dhcp-v4@bucknell.edu Wed Feb 7 14:58:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07736 for ; Wed, 7 Feb 2001 14:58:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f17Jrna28072; Wed, 7 Feb 2001 14:53:50 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f17Jrga14551 for ; Wed, 7 Feb 2001 14:53:43 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16718; Wed, 7 Feb 2001 11:53:39 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09200; Wed, 7 Feb 2001 14:53:38 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f17Jrbr106506; Wed, 7 Feb 2001 14:53:37 -0500 (EST) Message-Id: <200102071953.f17Jrbr106506@thunk.east.sun.com> From: Bill Sommerfeld To: DHCPv4 discussion list cc: DHCPv4 discussion list , "'subir@research.telcordia.com'" , urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt In-reply-to: Your message of "Wed, 07 Feb 2001 12:49:36 +0100." Reply-to: sommerfeld@east.sun.com Date: Wed, 07 Feb 2001 14:53:37 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: sommerfeld@thunk.east.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > [The reason I don't quite understand it is because I thought 802.11 was > using a single shared key for all the stations.] That's certainly how all the 802.11 boxes i've played with operate, and pretty much how an ad-hoc 802.11 LAN has to operate in the absence of a key management protocol known to the end stations. However, in "infrastructure" mode, all unicast traffic is sent between the wireless node and the access point it's associated with, so it would be relatively straightforward to have per-node keys as long as there was a key-distribution infrastructure in place to distribute all the per-node keys amongst all the base stations -- just makes for more work at the access point.. clients might be completely unaware of this. Multicast would get "interesting", though. I'd imagine that an AP would have to transmit N copies -- one for each of the N different keys; an alternative would be to continue to have a network key and use that to protect multicast. From owner-dhcp-v4@bucknell.edu Thu Feb 8 03:41:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02911 for ; Thu, 8 Feb 2001 03:41:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f188ZPa17603; Thu, 8 Feb 2001 03:35:25 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f188ZAa00814 for ; Thu, 8 Feb 2001 03:35:10 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f188TZR06033; Thu, 8 Feb 2001 00:29:36 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Cc: , Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Thu, 8 Feb 2001 00:35:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >[The reason I don't quite understand it is because I thought 802.11 was >using a single shared key for all the stations.] Actually, 802.11 supports per-session unicast keys as well as several global multicast keys. However, the initial implementations did not have enough on-chip memory to store all the per-session unicast keys, so that they only supported global multicast keying. The newer chipsets correct this problem. From owner-dhcp-v6@bucknell.edu Thu Feb 8 09:51:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08730; Thu, 8 Feb 2001 09:51:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f18El3a14195; Thu, 8 Feb 2001 09:47:03 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f18Ekwa04497 for ; Thu, 8 Feb 2001 09:46:58 -0500 (EST) Received: from rdroms-nt.cisco.com (rtp-dial-1-30.cisco.com [10.83.97.30]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00332 for ; Thu, 8 Feb 2001 09:46:40 -0500 (EST) Message-Id: <4.3.1.2.20010208060643.00af7c50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 08 Feb 2001 06:09:17 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: -16 rev of DHCPv6 spec In-Reply-To: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.c om> 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 Bernie asked the following questions about the DHCPv6 message header: At 10:36 AM 11/28/00 -0500, Bernie Volz wrote: >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > > From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ I'm a little leery of changing the DHCP message header based on the assumption that link-local addresses will always have the same format. Discussion? - Ralph From owner-dhcp-v6@bucknell.edu Thu Feb 8 11:47:59 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12730; Thu, 8 Feb 2001 11:47:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f18Gefa17538; Thu, 8 Feb 2001 11:40:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f18Gdta01425 for ; Thu, 8 Feb 2001 11:39:56 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f18GdlU02783 for ; Thu, 8 Feb 2001 10:39:48 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f18Gdgn25349 for ; Thu, 8 Feb 2001 10:39:42 -0600 (CST) Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt749 ; Thu Feb 08 10:40:03 2001 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <1P9FSAAT>; Thu, 8 Feb 2001 10:39:01 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F63F6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Thu, 8 Feb 2001 10:39:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091ED.C44903D0" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C091ED.C44903D0 Content-Type: text/plain; charset="iso-8859-1" Ralph, et al: I was just suggesting this as a possibility since we might want to minimize the size of the packets. I do think it best to use/send all 128-bits just to be safe (perhaps in the future, we might want to allow something other than a link-local address here). - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 08, 2001 6:09 AM To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Bernie asked the following questions about the DHCPv6 message header: At 10:36 AM 11/28/00 -0500, Bernie Volz wrote: >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > > From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ I'm a little leery of changing the DHCP message header based on the assumption that link-local addresses will always have the same format. Discussion? - Ralph ------_=_NextPart_001_01C091ED.C44903D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: -16 rev of DHCPv6 spec

Ralph, et al:

I was just suggesting this as a possibility since we = might want to minimize the size of the packets. I do think it best to = use/send all 128-bits just to be safe (perhaps in the future, we might = want to allow something other than a link-local address = here).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, February 08, 2001 6:09 AM
To: DHCPv6 discussion list
Subject: RE: -16 rev of DHCPv6 spec


Bernie asked the following questions about the DHCPv6 = message header:

At 10:36 AM 11/28/00 -0500, Bernie Volz wrote:

>- In most of the message headers, there is the = 16-byte client-link-local
>address. What about dropping the first 64-bits = of this (the prefix)? It
>would save 8-bytes/packet. This is just a = thought - there might be good
>reasons NOT to do this. But on the other hand, = it would remove the need for
>servers/relays to validate that the prefix is = the link local - instead, they
>pre-append the prefix when they need to use it = as a link-local address. So,
>if we were to do this, we'd call this 64-bit = field "interface ID" or
>something similar (at least based on RFC 2373 = terminology).
>
> From RFC 2373, it appears that link local = doesn't really consume the full
>64-bits before the interface-id, instead only = the first 10 bits are really
>specified (with the next 54-bits being zero, = though it is not clear that is
>REQUIRED).
>
>    |   = 10     |
>    |  = bits    |        54 = bits          = |          64 = bits           = |
>    = +----------+-------------------------+----------------------------+
>    = |1111111010|          = = 0            = ; |       interface = ID         |
>    = +----------+-------------------------+----------------------------+

I'm a little leery of changing the DHCP message = header based on the
assumption that link-local addresses will always = have the same
format.  Discussion?

- Ralph

------_=_NextPart_001_01C091ED.C44903D0-- From owner-dhcp-v6@bucknell.edu Thu Feb 8 12:30:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14122; Thu, 8 Feb 2001 12:30:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f18HRua29526; Thu, 8 Feb 2001 12:27:56 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f18HRha29055 for ; Thu, 8 Feb 2001 12:27:43 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f18HRfg26457 for ; Thu, 8 Feb 2001 11:27:41 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 8 Feb 2001 11:27:41 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7FYX>; Thu, 8 Feb 2001 11:27:41 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Thu, 8 Feb 2001 11:17:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091F3.0D2EB860" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C091F3.0D2EB860 Content-Type: text/plain; charset="iso-8859-1" bernie, FE80 is required or it is not a link local address. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday,February 08,2001 11:40 AM To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Ralph, et al: I was just suggesting this as a possibility since we might want to minimize the size of the packets. I do think it best to use/send all 128-bits just to be safe (perhaps in the future, we might want to allow something other than a link-local address here). - Bernie -----Original Message----- From: Ralph Droms [ mailto:rdroms@cisco.com ] Sent: Thursday, February 08, 2001 6:09 AM To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Bernie asked the following questions about the DHCPv6 message header: At 10:36 AM 11/28/00 -0500, Bernie Volz wrote: >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > > From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ I'm a little leery of changing the DHCP message header based on the assumption that link-local addresses will always have the same format. Discussion? - Ralph ------_=_NextPart_001_01C091F3.0D2EB860 Content-Type: text/html; charset="iso-8859-1" RE: -16 rev of DHCPv6 spec
bernie,
 
FE80 is required or it is not a link local address.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday,February 08,2001 11:40 AM
To: DHCPv6 discussion list
Subject: RE: -16 rev of DHCPv6 spec

Ralph, et al:

I was just suggesting this as a possibility since we might want to minimize the size of the packets. I do think it best to use/send all 128-bits just to be safe (perhaps in the future, we might want to allow something other than a link-local address here).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, February 08, 2001 6:09 AM
To: DHCPv6 discussion list
Subject: RE: -16 rev of DHCPv6 spec


Bernie asked the following questions about the DHCPv6 message header:

At 10:36 AM 11/28/00 -0500, Bernie Volz wrote:

>- In most of the message headers, there is the 16-byte client-link-local
>address. What about dropping the first 64-bits of this (the prefix)? It
>would save 8-bytes/packet. This is just a thought - there might be good
>reasons NOT to do this. But on the other hand, it would remove the need for
>servers/relays to validate that the prefix is the link local - instead, they
>pre-append the prefix when they need to use it as a link-local address. So,
>if we were to do this, we'd call this 64-bit field "interface ID" or
>something similar (at least based on RFC 2373 terminology).
>
> From RFC 2373, it appears that link local doesn't really consume the full
>64-bits before the interface-id, instead only the first 10 bits are really
>specified (with the next 54-bits being zero, though it is not clear that is
>REQUIRED).
>
>    |   10     |
>    |  bits    |        54 bits          |          64 bits           |
>    +----------+-------------------------+----------------------------+
>    |1111111010|           0             |       interface ID         |
>    +----------+-------------------------+----------------------------+

I'm a little leery of changing the DHCP message header based on the
assumption that link-local addresses will always have the same
format.  Discussion?

- Ralph

------_=_NextPart_001_01C091F3.0D2EB860-- From owner-dhcp-v6@bucknell.edu Thu Feb 8 12:53:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14835; Thu, 8 Feb 2001 12:53:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f18Hqha30974; Thu, 8 Feb 2001 12:52:43 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f18Hqfa08323 for ; Thu, 8 Feb 2001 12:52:41 -0500 (EST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 8 Feb 2001 09:25:36 -0800 Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 8 Feb 2001 09:26:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4643.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: -16 rev of DHCPv6 spec Date: Thu, 8 Feb 2001 09:26:20 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A688C55FE@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: -16 rev of DHCPv6 spec Thread-Index: AcCR3kPaEcu+piu8S4qZB2+jvkjvrgAFdFpA From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 08 Feb 2001 17:26:25.0944 (UTC) FILETIME=[43A70180:01C091F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f18Hqga07027 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit I think we should keep the message header generic and not specific. This would allow the protocol to handle scenarios that may develop as IPv6 evolves further.. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 08, 2001 3:09 AM To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Bernie asked the following questions about the DHCPv6 message header: At 10:36 AM 11/28/00 -0500, Bernie Volz wrote: >- In most of the message headers, there is the 16-byte client-link-local >address. What about dropping the first 64-bits of this (the prefix)? It >would save 8-bytes/packet. This is just a thought - there might be good >reasons NOT to do this. But on the other hand, it would remove the need for >servers/relays to validate that the prefix is the link local - instead, they >pre-append the prefix when they need to use it as a link-local address. So, >if we were to do this, we'd call this 64-bit field "interface ID" or >something similar (at least based on RFC 2373 terminology). > > From RFC 2373, it appears that link local doesn't really consume the full >64-bits before the interface-id, instead only the first 10 bits are really >specified (with the next 54-bits being zero, though it is not clear that is >REQUIRED). > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ I'm a little leery of changing the DHCP message header based on the assumption that link-local addresses will always have the same format. Discussion? - Ralph From owner-dhcp-v4@bucknell.edu Thu Feb 8 19:33:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21913 for ; Thu, 8 Feb 2001 19:33:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f190JsL14516; Thu, 8 Feb 2001 19:19:55 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f190JgL11814 for ; Thu, 8 Feb 2001 19:19:44 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1V3P>; Thu, 8 Feb 2001 19:19:23 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: "'subir@research.telcordia.com'" , DHCPv4 discussion list , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Thu, 8 Feb 2001 19:19:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Wednesday, February 07, 2001 11:50 AM To: George Tsirtsis Cc: 'subir@research.telcordia.com'; DHCPv4 discussion list; Erik Nordmark; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt > GT> Lets get this straight. If AAA is triggered at the DHCP RA as I suggest > then an attacker would have to spoof IP AND MAC addresses...which I think is > a bit harder....Furthermore, unless we get per packet/frame authentication > anything can be spoofed...so while DHCP is not an access control mechanism > today, it can certainly be made to be... 802.1X does per-port access control (great for switched Ethernets) and has some laguage (which I don't quite understand) about tying the access control to 802.11 per-station encryption with per-station keys. [The reason I don't quite understand it is because I thought 802.11 was using a single shared key for all the stations.] Thus 802.1X is an existence proof of an access control mechanism that is more fine grained than what you could ever do at L3 whether in a DHCP relay or somewhere else. GT> And I agree with you ...the counter argument of course is that you can not make a 802.X protocol work in non-802 link layers and so the potential need for a L3 mechanism. I do not think we disagree, do we? George From owner-dhcp-v4@bucknell.edu Fri Feb 9 11:14:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21686 for ; Fri, 9 Feb 2001 11:14:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f19G22L16128; Fri, 9 Feb 2001 11:02:02 -0500 (EST) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f19G1hL28852 for ; Fri, 9 Feb 2001 11:01:43 -0500 (EST) Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id LAA04505 for ; Fri, 9 Feb 2001 11:01:42 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38890) id <0G8H00B01Z5QXY@lmco.com> for dhcp-v4@bucknell.edu; Fri, 9 Feb 2001 11:01:03 -0500 (EST) Received: from caligula.agccs.lmco.com ([162.16.17.12]) by lmco.com (PMDF V5.2-32 #38890) with ESMTP id <0G8H006VAZ5K06@lmco.com> for dhcp-v4@bucknell.edu; Fri, 09 Feb 2001 11:00:57 -0500 (EST) Received: from kerman ([162.16.22.201]) by caligula.agccs.lmco.com (Netscape Messaging Server 3.6) with SMTP id AAA24B7; Fri, 09 Feb 2001 11:01:28 -0500 Date: Fri, 09 Feb 2001 11:01:35 -0500 From: Peter Thomas Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: DHCPv4 discussion list , subir@research.telcordia.com, urp@research.telcordia.com Message-id: <011201c092b1$9410ce90$c91610a2@agccs.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_9yERzXAo/efIicLTZ0G4rw)" X-Priority: 3 X-MSMail-priority: Normal References: <200102071953.f17Jrbr106506@thunk.east.sun.com> Reply-To: pthoma@agccs.lmco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --Boundary_(ID_9yERzXAo/efIicLTZ0G4rw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Do any of you have an opinion on whether the recently published WEP passive and active plaintext recovery and alteration vulnerabilities impact implementations of DHCPv4 (or 6) in wireless LANs? --Pete ----- Peter L. Thomas, System Architect Global Command and Control System - Army +1 (703)813-2684 pthoma@agccs.lmco.com ----- Original Message ----- From: Bill Sommerfeld To: DHCPv4 discussion list Cc: DHCPv4 discussion list ; 'subir@research.telcordia.com' ; urp@research.telcordia.com Sent: Wednesday, February 07, 2001 2:53 PM Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt > [The reason I don't quite understand it is because I thought 802.11 was > using a single shared key for all the stations.] That's certainly how all the 802.11 boxes i've played with operate, and pretty much how an ad-hoc 802.11 LAN has to operate in the absence of a key management protocol known to the end stations. However, in "infrastructure" mode, all unicast traffic is sent between the wireless node and the access point it's associated with, so it would be relatively straightforward to have per-node keys as long as there was a key-distribution infrastructure in place to distribute all the per-node keys amongst all the base stations -- just makes for more work at the access point.. clients might be completely unaware of this. Multicast would get "interesting", though. I'd imagine that an AP would have to transmit N copies -- one for each of the N different keys; an alternative would be to continue to have a network key and use that to protect multicast. --Boundary_(ID_9yERzXAo/efIicLTZ0G4rw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Do any of you have an opinion on whether the recently published WEP passive and active plaintext recovery and alteration vulnerabilities impact implementations of DHCPv4 (or 6) in wireless LANs?
 
--Pete

-----
Peter L. Thomas, System Architect
Global Command and Control System – Army

+1 (703)813-2684
pthoma@agccs.lmco.com

----- Original Message -----
Sent: Wednesday, February 07, 2001 2:53 PM
Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt

> [The reason I don't quite understand it is because I thought 802.11 was
> using a single shared key for all the stations.]

That's certainly how all the 802.11 boxes i've played with operate,
and pretty much how an ad-hoc 802.11 LAN has to operate in the absence
of a key management protocol known to the end stations.

However, in "infrastructure" mode, all unicast traffic is sent between
the wireless node and the access point it's associated with, so it
would be relatively straightforward to have per-node keys as long as
there was a key-distribution infrastructure in place to distribute all
the per-node keys amongst all the base stations -- just makes for more
work at the access point.. clients might be completely unaware of
this.

Multicast would get "interesting", though.  I'd imagine that an AP
would have to transmit N copies -- one for each of the N different
keys; an alternative would be to continue to have a network key and
use that to protect multicast.

--Boundary_(ID_9yERzXAo/efIicLTZ0G4rw)-- From owner-dhcp-v4@bucknell.edu Fri Feb 9 12:11:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23888 for ; Fri, 9 Feb 2001 12:11:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f19H1PL07388; Fri, 9 Feb 2001 12:01:25 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f19H1BL06617 for ; Fri, 9 Feb 2001 12:01:11 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA27985; Fri, 9 Feb 2001 09:00:42 -0800 (PST) Message-Id: <4.1.20010209114702.00bdcf00@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 09 Feb 2001 11:59:50 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt Cc: DHCPv4 discussion list In-Reply-To: <011201c092b1$9410ce90$c91610a2@agccs.lmco.com> References: <200102071953.f17Jrbr106506@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Pete, Yes, if you mean the results reported here: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html The passive attack exploits the relative lack of entropy (repeating sequence of the random pattern used in the stream cypher) in the WEP encryption. The active attack exploits the symmetry (XOR) of the encryption/decryption. Recall that DHCP works on old-fashioned coax multi-access networks with the same (lack of) privacy as broadcast radio (if you tap the wire). It is possible to mitigate the problem demonstrated in the above report by using different WEP keys for each session, rather than a shared key. Per-session keys are facilitated by the 802.1x authentication, which is possible with 802.11 wireless LANs. As has been pointed out before, access control works at layer two. John At 11:01 AM 02/09/2001 -0500, Peter Thomas wrote: >Do any of you have an opinion on whether the recently published WEP >passive and active plaintext recovery and alteration vulnerabilities >impact implementations of DHCPv4 (or 6) in wireless LANs? From owner-dhcp-v4@bucknell.edu Fri Feb 9 12:31:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25105 for ; Fri, 9 Feb 2001 12:31:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f19HH6L29731; Fri, 9 Feb 2001 12:17:06 -0500 (EST) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f19HGqL02185 for ; Fri, 9 Feb 2001 12:16:57 -0500 (EST) Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA04289 for ; Fri, 9 Feb 2001 12:16:50 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38890) id <0G8I00C012MYDA@lmco.com> for dhcp-v4@bucknell.edu; Fri, 9 Feb 2001 12:16:11 -0500 (EST) Received: from caligula.agccs.lmco.com ([162.16.17.12]) by lmco.com (PMDF V5.2-32 #38890) with ESMTP id <0G8I00KWD2MW0R@lmco.com> for dhcp-v4@bucknell.edu; Fri, 09 Feb 2001 12:16:09 -0500 (EST) Received: from kerman ([162.16.22.201]) by caligula.agccs.lmco.com (Netscape Messaging Server 3.6) with SMTP id AAA3199; Fri, 09 Feb 2001 12:16:40 -0500 Date: Fri, 09 Feb 2001 12:16:47 -0500 From: Peter Thomas Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: DHCPv4 discussion list Message-id: <01ed01c092bc$158bbc00$c91610a2@agccs.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_swMJkay6fUUwkUH+TyOIdQ)" X-Priority: 3 X-MSMail-priority: Normal References: <200102071953.f17Jrbr106506@thunk.east.sun.com> <4.1.20010209114702.00bdcf00@diablo.cisco.com> Reply-To: pthoma@agccs.lmco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --Boundary_(ID_swMJkay6fUUwkUH+TyOIdQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT John, thanks for your thoughts. That was indeed the precise report I was referring to (and I apologize for being too slack to dig through my archives and pull out the link myself). Thinking back on the draft, all the relayed AAA traffic was (presumably) happening on the back-end wired (as opposed to the client, possibly wireless) network media. I disagree, however, that physically a tapped physical medium is equivalent to a remotely tapped wireless medium--especially one which you were led to believe (prior to the publication of this vulnerability) was secure. I'm not sure how per-session key negotiation negates this attack--considering the potentially large number of sessions that are opened, deciphering the key stream from a search space of (recognizable?) key negotiation transactions seems possible (just more time consuming). I don't want to risk wandering too far afield from the subject draft here, so feel free to close the loop on this or let it drop as you choose. -Pete ----- Peter L. Thomas, System Architect Global Command and Control System - Army +1 (703)813-2684 pthoma@agccs.lmco.com ----- Original Message ----- From: John Schnizlein To: pthoma@agccs.lmco.com Cc: DHCPv4 discussion list Sent: Friday, February 09, 2001 11:59 AM Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt Pete, Yes, if you mean the results reported here: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html The passive attack exploits the relative lack of entropy (repeating sequence of the random pattern used in the stream cypher) in the WEP encryption. The active attack exploits the symmetry (XOR) of the encryption/decryption. Recall that DHCP works on old-fashioned coax multi-access networks with the same (lack of) privacy as broadcast radio (if you tap the wire). It is possible to mitigate the problem demonstrated in the above report by using different WEP keys for each session, rather than a shared key. Per-session keys are facilitated by the 802.1x authentication, which is possible with 802.11 wireless LANs. As has been pointed out before, access control works at layer two. John At 11:01 AM 02/09/2001 -0500, Peter Thomas wrote: >Do any of you have an opinion on whether the recently published WEP >passive and active plaintext recovery and alteration vulnerabilities >impact implementations of DHCPv4 (or 6) in wireless LANs? --Boundary_(ID_swMJkay6fUUwkUH+TyOIdQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
John, thanks for your thoughts.  That was indeed the precise report I was referring to (and I apologize for being too slack to dig through my archives and pull out the link myself).  Thinking back on the draft, all the relayed AAA traffic was (presumably) happening on the back-end wired (as opposed to the client, possibly wireless) network media.  I disagree, however, that physically a tapped physical medium is equivalent to a remotely tapped wireless medium--especially one which you were led to believe (prior to the publication of this vulnerability) was secure.
 
I'm not sure how per-session key negotiation negates this attack--considering the potentially large number of sessions that are opened, deciphering the key stream from a search space of (recognizable?) key negotiation transactions seems possible (just more time consuming).
 
I don't want to risk wandering too far afield from the subject draft here, so feel free to close the loop on this or let it drop as you choose.
 
-Pete

-----
Peter L. Thomas, System Architect
Global Command and Control System – Army

+1 (703)813-2684
pthoma@agccs.lmco.com

----- Original Message -----
Sent: Friday, February 09, 2001 11:59 AM
Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt

Pete,

Yes, if you mean the results reported here:
http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
The passive attack exploits the relative lack of entropy (repeating
sequence of the random pattern used in the stream cypher) in the WEP
encryption. The active attack exploits the symmetry (XOR) of the
encryption/decryption.

Recall that DHCP works on old-fashioned coax multi-access networks
with the same (lack of) privacy as broadcast radio (if you tap the wire).

It is possible to mitigate the problem demonstrated in the above report
by using different WEP keys for each session, rather than a shared key.
Per-session keys are facilitated by the 802.1x authentication, which is
possible with 802.11 wireless LANs.

As has been pointed out before, access control works at layer two.

John

At 11:01 AM 02/09/2001 -0500, Peter Thomas wrote:
>Do any of you have an opinion on whether the recently published WEP
>passive and active plaintext recovery and alteration vulnerabilities
>impact implementations of DHCPv4 (or 6) in wireless LANs?

--Boundary_(ID_swMJkay6fUUwkUH+TyOIdQ)-- From owner-dhcp-v6@bucknell.edu Sat Feb 10 09:49:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25797; Sat, 10 Feb 2001 09:49:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1AEkFL11737; Sat, 10 Feb 2001 09:46:15 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1AEkEL21522; Sat, 10 Feb 2001 09:46:14 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA17607; Sat, 10 Feb 2001 06:46:12 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1AEjwX04615; Sat, 10 Feb 2001 06:45:58 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA22107; Sat, 10 Feb 2001 06:45:56 -0800 (PST) Message-Id: <4.3.1.2.20010210094026.00b1f5b0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 10 Feb 2001 09:46:04 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in Minneapolis 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 The DHC WG has tentatively been scheduled for two meetings in Minneapolis. We will use the Monday afternoon meeting for DHCPv4 issues and the Tuesday morning meeting for DHCPv6; see below for DHC meetings and for concurrently scheduled WG meetings. Please submit any agenda items for either session to me so I can put together agendas for both meetings. - Ralph MONDAY, March 19, 2001 1530-1730 Afternoon Sessions II APP impp Instant Messaging and Presence Protocol WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG RTG pim Protocol Independent Multicast WG SEC secsh Secure Shell WG TSV nfsv4 Network File System Version 4 WG TUESDAY, March 20, 2001 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG msdp Multicast Source Discovery Protocol WG SEC ipsra IP Security Remote Access WG TSV sip Session Initiation Protocol WG From owner-dhcp-v4@bucknell.edu Sat Feb 10 09:51:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25822 for ; Sat, 10 Feb 2001 09:51:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1AEkFL09849; Sat, 10 Feb 2001 09:46:15 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1AEkEL21522; Sat, 10 Feb 2001 09:46:14 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA17607; Sat, 10 Feb 2001 06:46:12 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1AEjwX04615; Sat, 10 Feb 2001 06:45:58 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA22107; Sat, 10 Feb 2001 06:45:56 -0800 (PST) Message-Id: <4.3.1.2.20010210094026.00b1f5b0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 10 Feb 2001 09:46:04 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meetings in Minneapolis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The DHC WG has tentatively been scheduled for two meetings in Minneapolis. We will use the Monday afternoon meeting for DHCPv4 issues and the Tuesday morning meeting for DHCPv6; see below for DHC meetings and for concurrently scheduled WG meetings. Please submit any agenda items for either session to me so I can put together agendas for both meetings. - Ralph MONDAY, March 19, 2001 1530-1730 Afternoon Sessions II APP impp Instant Messaging and Presence Protocol WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG RTG pim Protocol Independent Multicast WG SEC secsh Secure Shell WG TSV nfsv4 Network File System Version 4 WG TUESDAY, March 20, 2001 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG msdp Multicast Source Discovery Protocol WG SEC ipsra IP Security Remote Access WG TSV sip Session Initiation Protocol WG From owner-dhcp-v4@bucknell.edu Sat Feb 10 10:08:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26000 for ; Sat, 10 Feb 2001 10:08:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1AF5pL02951; Sat, 10 Feb 2001 10:05:51 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1AF5ZL24010 for ; Sat, 10 Feb 2001 10:05:35 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1AExkR23859; Sat, 10 Feb 2001 06:59:46 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Sat, 10 Feb 2001 07:06:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C0932F.F48DBED0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01ed01c092bc$158bbc00$c91610a2@agccs.lmco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C0932F.F48DBED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I'm not sure how per-session key negotiation negates this attack--considering the potentially large number of sessions that are opened, deciphering the key stream > from a search space of (recognizable?) key negotiation transactions seems possible (just more time consuming). Rather than taking this mailing list into completely unrelated topics, have a look at the following references: http://www.drizzle.com/~aboba/IEEE/1-18.zip http://www.drizzle.com/~aboba/IEEE/baseline.ppt.gz http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz ------=_NextPart_000_0004_01C0932F.F48DBED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 > I'm not sure how = per-session key=20 negotiation negates this attack--considering the potentially large = number of=20 sessions that are opened, deciphering the key stream  
> from a search space of = (recognizable?) key=20 negotiation transactions seems possible (just more time consuming). 
 
Rather than taking this mailing list into = completely=20 unrelated topics, have a look at the following=20 references:
 
http://www.drizzle.c= om/~aboba/IEEE/1-18.zip
http://www.dr= izzle.com/~aboba/IEEE/baseline.ppt.gz
http://www.d= rizzle.com/~aboba/IEEE/8021x-d10.pdf.gz
 
 
 
 
 
------=_NextPart_000_0004_01C0932F.F48DBED0-- From owner-dhcp-v4@bucknell.edu Mon Feb 12 04:46:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03088 for ; Mon, 12 Feb 2001 04:46:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1C9dWL03683; Mon, 12 Feb 2001 04:39:32 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1C9dFL29169 for ; Mon, 12 Feb 2001 04:39:15 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07791; Mon, 12 Feb 2001 01:39:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id BAA05038; Mon, 12 Feb 2001 01:39:06 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1C9csR684159; Mon, 12 Feb 2001 01:38:55 -0800 (PST) Date: Sun, 11 Feb 2001 18:36:51 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: "'Erik Nordmark'" , "'subir@research.telcordia.com'" , DHCPv4 discussion list , urp@research.telcordia.com In-Reply-To: "Your message with ID" 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 > > GT> And I agree with you ...the counter argument of course is that you can > not make a 802.X protocol work in non-802 link layers and so the potential > need for a L3 mechanism. I do not think we disagree, do we? I think we sort of disagree. My point is that any L3 mechanism will always provide weaker enforcement of access control. Thus if there is a critical link layer that doesn't have L2 support for this, it would seem prudent to add the access control at the link layer. Given that PPP, 802, and the various cellular radio protocols presumably already have this, what other link layers do people worry about? Erik From owner-dhcp-v4@bucknell.edu Mon Feb 12 04:46:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03099 for ; Mon, 12 Feb 2001 04:46:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1C9k0L24209; Mon, 12 Feb 2001 04:46:00 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1C9eLL20280 for ; Mon, 12 Feb 2001 04:40:21 -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 BAA12393; Mon, 12 Feb 2001 01:40:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id BAA05225; Mon, 12 Feb 2001 01:40:17 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1C9eER684379; Mon, 12 Feb 2001 01:40:15 -0800 (PST) Date: Sun, 11 Feb 2001 21:52:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: Erik Nordmark , DHCPv4 discussion list , aboba@internaut.com, urp@research.telcordia.com In-Reply-To: "Your message with ID" <3A7F448E.4E97EA4B@research.telcordia.com> 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 > I agree, but we are trying to segregate the user to network registration > from access control. Moreover, the proposal is not to build an IP-layer > access control protocol. I think, access control via firewall/ policing > at the access router is > a policy or architectural issue which is beyond the scope of BURP. In > a nutshell, what we want to achieve is a Local Security Association (LSA) > between > the user and the network when an user enters into a visited network. > However, the generated LSA between user and network can be used to help with > access control either above or below the IP layer. I think a BoF and potential subsequent WG needs to look at a problem which, when solved, provides some benefits. I don't see "user registration" i.e. auhentication without any access control as providing any benefits. Of course, the above doesn't mean that the authentication and access control parts need to be tangled together - they can very well be different functions even provided by different protocols. But the solution needs to include both. > > If access control needs to be done at L2 (or L1) what are the benefits of > > having L3 or higher protocols for authentication? > > As an example, Mobile IP clients need a L3 authentication even if there > exists an authentication at L2. Similarly, many IETF protocols have their > own (either in built or extended) end-client (user-node) that interacts with > AAA infrastructure. But we need something when those protocols are absent or > not required. A generic user registration protocol at the application layer > may help other protocols to use the same LSA for authentication without > extending individual protocol to work with AAA infrastructure. The mobile IP L3 authentication is made to the home agent, right? If mobile IP runs on an infrastructure which already has L2 AAA functionality, all that mobile IP needs to provide is the home agent authenticating the mobile to avoid some imposter redirecting traffic. But the access control and accounting could all be done at L2. Erik From owner-dhcp-v4@bucknell.edu Mon Feb 12 09:10:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06840 for ; Mon, 12 Feb 2001 09:10:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1CE3vL03768; Mon, 12 Feb 2001 09:03:57 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1CE3jL13685 for ; Mon, 12 Feb 2001 09:03:45 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1WVG>; Mon, 12 Feb 2001 09:03:28 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: DHCPv4 discussion list , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 12 Feb 2001 09:03:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Let me also agree to Pat's point which is not limited to cdma2000 but makes sense as a generic separation between L2 and L2 AAA functions. L2 AAA only gives access to the specific L2 resources and as I said before this has nothing to do with AAA in the IP layer. This is emphasized when the Link Layer is not one hop but a whole network/infrastructure as in a lot of 2G/3G scenarios. L3 AAA has to be employed separately to provide access to L2 (Internet) resources that the Link Layer, very often, is not even aware of. On top of that we also have Application Layer AAA that is also independent from L3 AAA...e.g.: access to specific sites/servers etc. I think there is temptation to integrate some of L2/L3 AAA and indeed in some circumstances it might even be possible....but I still think the above is not the general case. To return to my favorite example of always-on...per port L2 authentication could be static and subscription based. L3 AAA on top of it could supply customer/user profiles as well as accounting and authorization to specific services. Regards George -----Original Message----- From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] Sent: Monday, February 12, 2001 8:32 AM To: Erik Nordmark Cc: Subir Das; DHCPv4 discussion list; aboba@internaut.com; urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt > The mobile IP L3 authentication is made to the home agent, right? > If mobile IP runs on an infrastructure which already has L2 AAA > functionality, all that mobile IP needs to provide is the home agent > authenticating the mobile to avoid some imposter redirecting traffic. > But the access control and accounting could all be done at L2. > The issue with the above is that in the cdma2000 world, AAA will be used to auth* the link connection. However, the AAA server that "owns" the device is different from the AAA server that is "owns" the Home Agent. In a corporate outsourcing model, the L2 AAA is owned by the carrier, while the L3 AAA is owned by the corporate customer. One provides access to the spectrum, the other access to the network (be it a corporate or general Internet access). PatC From owner-dhcp-v4@bucknell.edu Mon Feb 12 12:33:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15681 for ; Mon, 12 Feb 2001 12:33:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1CHQGL13869; Mon, 12 Feb 2001 12:26:16 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1CHQ0L10888 for ; Mon, 12 Feb 2001 12:26:00 -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 JAA11551; Mon, 12 Feb 2001 09:25:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA20052; Mon, 12 Feb 2001 09:25:50 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1CHPaR740057; Mon, 12 Feb 2001 09:25:37 -0800 (PST) Date: Mon, 12 Feb 2001 18:25:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: "'Patrice Calhoun'" , Erik Nordmark , DHCPv4 discussion list , urp@research.telcordia.com In-Reply-To: "Your message with ID" 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 > I think there is temptation to integrate some of L2/L3 AAA and indeed in > some circumstances it might even be possible....but I still think the above > is not the general case. To return to my favorite example of always-on...per > port L2 authentication could be static and subscription based. L3 AAA on top > of it could supply customer/user profiles as well as accounting and > authorization to specific services. This sounds a lot different that "provide what PPP authentication and access control does for PPP links for any link layer". While I can sort of understand that granting L2 connectivity is different than granting L3 connectivity (even though PPP doesn't make such a distinction) I think the issue of AAA for applications was sent off to IRTF/AAARCH to do some research. So I don't see how the last part relates to the BoF proposal. Erik From owner-dhcp-v4@bucknell.edu Mon Feb 12 12:55:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16412 for ; Mon, 12 Feb 2001 12:55:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1CHqaL16554; Mon, 12 Feb 2001 12:52:36 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1CHqEL10125 for ; Mon, 12 Feb 2001 12:52:15 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1XA5>; Mon, 12 Feb 2001 12:51:57 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: DHCPv4 discussion list , urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 12 Feb 2001 12:51:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Monday, February 12, 2001 12:25 PM To: George Tsirtsis Cc: 'Patrice Calhoun'; Erik Nordmark; DHCPv4 discussion list; urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt > I think there is temptation to integrate some of L2/L3 AAA and indeed in > some circumstances it might even be possible....but I still think the above > is not the general case. To return to my favorite example of always-on...per > port L2 authentication could be static and subscription based. L3 AAA on top > of it could supply customer/user profiles as well as accounting and > authorization to specific services. This sounds a lot different that "provide what PPP authentication and access control does for PPP links for any link layer". While I can sort of understand that granting L2 connectivity is different than granting L3 connectivity (even though PPP doesn't make such a distinction) I think the issue of AAA for applications was sent off to IRTF/AAARCH to do some research. So I don't see how the last part relates to the BoF proposal. GT> PPP confuses things because it is integrated L1/L2/L3...which reminds us that strict layering only works in theory...but I think we are becoming too philosophical and although I am of Greek origin I rather stick to engineering :-) George From owner-dhcp-v4@bucknell.edu Tue Feb 13 09:39:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20112 for ; Tue, 13 Feb 2001 09:39:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1DEQqL18748; Tue, 13 Feb 2001 09:26:53 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1DEQkL12405 for ; Tue, 13 Feb 2001 09:26:46 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23821; Tue, 13 Feb 2001 06:26:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id GAA13414; Tue, 13 Feb 2001 06:26:25 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1DEQ9R945360; Tue, 13 Feb 2001 06:26:19 -0800 (PST) Date: Tue, 13 Feb 2001 15:25:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt To: DHCPv4 discussion list Cc: Erik.Nordmark@eng.sun.com, G.Tsirtsis@flarion.com, pcalhoun@nasnfs.eng.sun.com, dhcp-v4@bucknell.edu, urp@research.telcordia.com In-Reply-To: "Your message with ID" <01D91AFB08B6D211BFD00008C7EABAE10527A7B5@eseis04nok> 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 > Erik, > > Isn't AAA for applications still a different issue from AAA for L3 services? Yes, I think it would be a very different issue. Erik From owner-dhcp-v4@bucknell.edu Wed Feb 14 06:08:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26040 for ; Wed, 14 Feb 2001 06:08:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1EAx9L23765; Wed, 14 Feb 2001 05:59:09 -0500 (EST) Received: from coral.bucknell.edu (coral.bucknell.edu [134.82.7.4]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1EAwxL01306 for ; Wed, 14 Feb 2001 05:58:59 -0500 (EST) Received: from smtp.alpha-soft.com ([12.8.241.171]) by coral.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA14582 for ; Wed, 14 Feb 2001 05:58:55 -0500 (EST) Received: from offset [130.244.215.181] by smtp.alpha-soft.com (SMTPD32-6.00) id A4476A14006E; Wed, 14 Feb 2001 05:56:07 -0500 Reply-To: From: "Bud Millwood" To: DHCPv4 discussion list Subject: Implementing support for relay agent options Date: Wed, 14 Feb 2001 12:06:06 +0100 Message-ID: <000001c09676$20f37f70$3201a8c0@offset.weird.se> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I have added support to my DHCP server for option 82, Relay Agent Info, but I have some questions: To help my server limit the number of addresses I lease to a given customer, the CMTS will tag all DHCP DISCOVERs with a Circuit and/or Remote ID. This means that both the CM-originated DISCOVERs and CPE-originated DISCOVERs (from behind that same CM) will all have the same Remote ID. If this is the case, I simply limit the number of active leases per RID. Is this correct? Is there any reason to implement lease limitations per Circuit ID? I don't see that there is because there may be many CMs per circuit. I do provide Circuit ID in lease logs, but I am not using it for address limitation. I understand that an administrator may want to assign certain DHCP options based on a CID, but that's another story. Have I got this right? Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com From owner-dhcp-v4@bucknell.edu Wed Feb 14 11:47:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06369 for ; Wed, 14 Feb 2001 11:47:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1EGbqL27623; Wed, 14 Feb 2001 11:37:52 -0500 (EST) Received: from mail.totalise.co.uk (mail.totalise.co.uk [212.1.157.18]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1EGbkL27294 for ; Wed, 14 Feb 2001 11:37:47 -0500 (EST) Received: from takng1 [47.160.37.89] (takng@totalise.co.uk) by mail.totalise.co.uk; Wed, 14 Feb 2001 16:37:29 +0000 X-WM-Posted-At: mail.totalise.co.uk; Wed, 14 Feb 01 16:37:29 +0000 Message-ID: <017e01c096a4$cfb236e0$5925a02f@europe.nortel.com> From: "Tak Ng" To: DHCPv4 discussion list Subject: DHCP extension Date: Wed, 14 Feb 2001 16:40:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Reply-To: takng@totalise.co.uk Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I am investigating the problem of dynamically allocating multiple IP addresses to a single MAC. Could anybody tell me whether there is any work being done in extending DHCP to cater for this? Thanks. From owner-dhcp-v4@bucknell.edu Wed Feb 14 11:55:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06692 for ; Wed, 14 Feb 2001 11:55:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1EGrKL27971; Wed, 14 Feb 2001 11:53:20 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1EGrCL18030 for ; Wed, 14 Feb 2001 11:53:12 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f1EGovJ27306; Wed, 14 Feb 2001 08:51:01 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f1EGmSF07442; Wed, 14 Feb 2001 08:48:29 -0800 (PST) Message-Id: <200102141648.f1EGmSF07442@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP extension In-Reply-To: Message from "Tak Ng" of "Wed, 14 Feb 2001 16:40:15 GMT." <017e01c096a4$cfb236e0$5925a02f@europe.nortel.com> Date: Wed, 14 Feb 2001 09:48:28 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I am investigating the problem of dynamically allocating multiple IP > addresses to a single MAC. Could anybody tell me whether there is any work > being done in extending DHCP to cater for this? Thanks. It's no problem - just make up a different client identifier for each IP address you want, and have a seperate state machine for each client. You can see how this is done in the ISC DHCP client if you are interested - look at the implementation of the "pseudo" statement. You need the client identifier to be something that's likely to be unique - I'd suggest using the MAC address followed by a two-byte interface index, or something like that. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Feb 15 11:55:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23173 for ; Thu, 15 Feb 2001 11:55:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1FGnJL09591; Thu, 15 Feb 2001 11:49:19 -0500 (EST) Received: from styx.uwaterloo.ca (IDENT:root@styx.uwaterloo.ca [129.97.40.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1FGn4L20425 for ; Thu, 15 Feb 2001 11:49:04 -0500 (EST) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id f1FGn2124621 for ; Thu, 15 Feb 2001 11:49:02 -0500 Date: Thu, 15 Feb 2001 11:49:02 -0500 (EST) From: Roop Mukherjee To: DHCPv4 discussion list Subject: Why authenticate with DHCP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: bmukherj@styx.uwaterloo.ca Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In the midst of all the debate over the I did not see any mention of the nomadic user scenario: A user with an IP device wishes to access a network away from home. He can't always rely PPP as, well its 'point to point', and not all networks are (e.g. wireless). In its present form the DHCP server will not recognize the user, so it cant even send packets to a network entity in him home network. What is such a user to do ? Do we expect his home network operator to make special arangements with the visited network operator or do we allow a common IP level mechanism to make these arrangements for him? If the later is preferable, this negotiation (in form of a widely used AAA protocol) should happen before his IP stack is configured. Given the expected growth of a variety of wireless data networks and nomadic users using DHCP, should this not be motivation to incorporate some nomadic access mechanism into DHCP? -- Roop ________________________________________ From owner-dhcp-v4@bucknell.edu Thu Feb 15 19:28:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02843 for ; Thu, 15 Feb 2001 19:28:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1G0LKL29110; Thu, 15 Feb 2001 19:21:20 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1G0L5L16312 for ; Thu, 15 Feb 2001 19:21:06 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id QAA00335; Thu, 15 Feb 2001 16:20:51 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01457; Thu, 15 Feb 01 16:20:30 -0800 Date: Thu, 15 Feb 2001 16:20:30 -0800 (GMT-0800) From: "Bernard D. Aboba" To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: Why authenticate with DHCP In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Your question relates to inter-domain DHCP authentication. It is true that draft-ietf-dhc-authentication-16.txt does not address this scenario. However, other drafts do address this, in different ways: draft-hornstein-dhc-kerbauth-04.txt (via PKINIT or Kerb cross-realm) draft-smedvinsky-dhc-kerbauth-01.txt (ditto) There was a also a draft on DHCP authentication via PKI that handled this case. From owner-dhcp-v4@bucknell.edu Thu Feb 15 20:30:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03666 for ; Thu, 15 Feb 2001 20:30:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1G1NIL02897; Thu, 15 Feb 2001 20:23:22 -0500 (EST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1G1N9L25268 for ; Thu, 15 Feb 2001 20:23:09 -0500 (EST) Received: from localhost (waa@localhost) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f1G1N6O24688; Thu, 15 Feb 2001 20:23:06 -0500 (EST) Date: Thu, 15 Feb 2001 20:23:05 -0500 (EST) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list , waa@cs.umd.edu Subject: Re: Why authenticate with DHCP In-Reply-To: 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 At the authentication sub-working group held many moons ago, we discussed the issues of inter-domain roaming. And unfortunately, didn't get very far. But, I'll try and answer your questions as best I can. > In the midst of all the debate over the I > did not see any mention of the nomadic user scenario: A user with an IP > device wishes to access a network away from home. He can't always rely PPP > as, well its 'point to point', and not all networks are > (e.g. wireless). In its present form the DHCP server will not recognize > the user, so it cant even send packets to a network entity in him home > network. > > What is such a user to do ? > > Do we expect his home network operator to make special arangements with > the visited network operator or do we allow a common IP level mechanism to > make these arrangements for him? If the later is preferable, this > negotiation (in form of a widely used AAA protocol) should happen before > his IP stack is configured. Given the expected growth of a variety > of wireless data networks and nomadic users using DHCP, should this > not be motivation to incorporate some nomadic access mechanism into > DHCP? > I believe the current DHCP authentication draft can support this type of situation in several ways. First, the user could get a shared secret from the network he wants to join out-of-band. An inconvience, yes, but with the lack of a global PKI- probably the easiest. The second approach, unfortunately, requires a shared PKI. With respect to wireless, either the people are going to run their wireless network completely open- i.e. no access control and no WEP. Or, they'll control the access in some way. In the former, there is no problem. DHCP works as it always has. In the latter, some form of out-of-band coordination is required to either get the WEP key, provide your MAC address, and/or get the network name (SSID). We're actually working on these issues at Univ. of Maryland as I speak. We've designed a mechanism for wireless access piggy backing on DHCP authentication, as well as support for WEP key mangement (which is badly needed). We have a rough prototype finished, but we need to polish it more. I expect we'll submit at least two drafts on a new authentication mechanism and a new option for WEP keys soon. Bill From owner-dhcp-v4@bucknell.edu Fri Feb 16 06:58:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26828 for ; Fri, 16 Feb 2001 06:58:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GBr3L15676; Fri, 16 Feb 2001 06:53:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GBr1L26677 for ; Fri, 16 Feb 2001 06:53:01 -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 GAA26443; Fri, 16 Feb 2001 06:52:59 -0500 (EST) Message-Id: <200102161152.GAA26443@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-leasequery-01.txt Date: Fri, 16 Feb 2001 06:52:59 -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 Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-01.txt Pages : 22 Date : 15-Feb-01 Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations 'glean' location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-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-leasequery-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-leasequery-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: <20010215122039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Feb 16 08:19:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28142 for ; Fri, 16 Feb 2001 08:19:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GDDYL09908; Fri, 16 Feb 2001 08:13:34 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GDDFL28631 for ; Fri, 16 Feb 2001 08:13:15 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1GDDDd08704 for ; Fri, 16 Feb 2001 14:13:13 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 16 14:13:01 2001 +0100 Received: by esealnt747.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 16 Feb 2001 14:12:27 +0100 Message-ID: <319B232179B9D4118B030008C786CE7F0111F24A@edkchnt101.lmd.ericsson.se> From: "Henrik Skovsgaard Pedersen (LMD)" To: DHCPv4 discussion list Subject: DHCP relay - RFC 2131 clarification Date: Fri, 16 Feb 2001 13:53:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Henrik.Skovsgaard.Pedersen@lmd.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a question concerning the DHCP relay agent. According to RFC 2131 DHCP relay works on the following way: If 'giaddr' in the discover message is non-zero the DHCP server sends the offer to the server port (port 67) on the host whose address appears in 'giaddr'. Questions: Is it mandatory for a DHCP server which is compliant to RFC 2131 to support DHCP relay? Is DHCP relay a feature that MUST be implemented or a feature that SHOULD be implemented in the DHCP server? Kind regards, Henrik S. Pedersen System Designer, L.M. Ericsson From owner-dhcp-v4@bucknell.edu Fri Feb 16 15:38:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08985 for ; Fri, 16 Feb 2001 15:38:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GKUhL02582; Fri, 16 Feb 2001 15:30:43 -0500 (EST) Received: from styx.uwaterloo.ca (IDENT:root@styx.uwaterloo.ca [129.97.40.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GKUbL31778 for ; Fri, 16 Feb 2001 15:30:38 -0500 (EST) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id f1GKUMO13096; Fri, 16 Feb 2001 15:30:22 -0500 Date: Fri, 16 Feb 2001 15:30:22 -0500 (EST) From: Roop Mukherjee To: DHCPv4 discussion list cc: DHCPv4 discussion list , aboba@internaut.com, gageb@nortel.com Subject: Re: Why authenticate with DHCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: bmukherj@styx.uwaterloo.ca Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for the responses, Bill and Bernard D. Aboba. My concern was not just about cross domain authentication. The scenario of providing service to nomadic users requires the networks to not just authenticate the user by cooperating among each other, but also involves all the other issues associated with managing a large population of subscribers. The service provider networks of today after verifying the identity of the user may wish to provide severals levels of authorization (e.g. filters), bill the users for usage, provide VPN support, to name a few. The AAA protocols provide a scalable means of doing all this. The AAA protocols are being used in the service provider networks for dial up (PPP) users. With new types of networks that do not adhere to the PPP scenarios DHCP may be a potential alternative. My question then is what is needed for DHCP to be a viable alternative in commenrcial access networks? One possibility may be to add in general mechanisms to support AAA interactions, instead of just adding in a specific mechanism that performs cross domain authentication using Kerberos. -- Roop On Thu, 15 Feb 2001, William A. Arbaugh wrote: > > At the authentication sub-working group held many moons ago, we discussed > the issues of inter-domain roaming. And unfortunately, didn't get very > far. But, I'll try and answer your questions as best I can. > > > In the midst of all the debate over the I > > did not see any mention of the nomadic user scenario: A user with an IP > > device wishes to access a network away from home. He can't always rely PPP > > as, well its 'point to point', and not all networks are > > (e.g. wireless). In its present form the DHCP server will not recognize > > the user, so it cant even send packets to a network entity in him home > > network. > > > > What is such a user to do ? > > > > Do we expect his home network operator to make special arangements with > > the visited network operator or do we allow a common IP level mechanism to > > make these arrangements for him? If the later is preferable, this > > negotiation (in form of a widely used AAA protocol) should happen before > > his IP stack is configured. Given the expected growth of a variety > > of wireless data networks and nomadic users using DHCP, should this > > not be motivation to incorporate some nomadic access mechanism into > > DHCP? > > > I believe the current DHCP authentication draft can support this type of > situation in several ways. First, the user could get a shared secret from > the network he wants to join out-of-band. An inconvience, yes, but with > the lack of a global PKI- probably the easiest. The second approach, > unfortunately, requires a shared PKI. > > With respect to wireless, either the people are going to run their > wireless network completely open- i.e. no access control and no WEP. Or, > they'll control the access in some way. In the former, there is no > problem. DHCP works as it always has. In the latter, some form of > out-of-band coordination is required to either get the WEP key, provide > your MAC address, and/or get the network name (SSID). We're actually > working on these issues at Univ. of Maryland as I speak. We've designed a > mechanism for wireless access piggy backing on DHCP authentication, as > well as support for WEP key mangement (which is badly needed). We have a > rough prototype finished, but we need to polish it more. I expect we'll > submit at least two drafts on a new authentication mechanism and a new > option for WEP keys soon. > > Bill > -- ________________________________________ From owner-dhcp-v4@bucknell.edu Fri Feb 16 16:33:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10061 for ; Fri, 16 Feb 2001 16:33:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GLSJL10497; Fri, 16 Feb 2001 16:28:19 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GLSHL16269 for ; Fri, 16 Feb 2001 16:28:17 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA23697; Fri, 16 Feb 2001 13:27:51 -0800 (PST) Message-Id: <4.1.20010216154744.00995540@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Feb 2001 16:11:41 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Why authenticate with DHCP? Cc: DHCPv4 discussion list In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 03:30 PM 02/16/2001 -0500, Roop Mukherjee wrote: >... The AAA protocols are being used in the service provider networks >for dial up (PPP) users. With new types of networks that do not adhere >to the PPP scenarios DHCP may be a potential alternative. Yes, but another alternative that has gained some momentum already is to use the same AAA protocols (RADIUS) from the network access point that supports any of the IEEE 802 link-layer protocols. This is the IEEE 802.1x approach. Following this alternative, the question becomes how to coordinate between the port-level access control of 802.1x (and its AAA), and DHCP. Coordination with DHCP could provide the sort of parameters to the 802-connected host that PPP provides over dial-up lines. Recall that AAA can interact with PPP to assign host IP addresses, etc. >My question then is what is needed for DHCP to be a viable alternative >in commenrcial access networks? One possibility may be to add in >general mechanisms to support AAA interactions, instead of just adding >in a specific mechanism that performs cross domain authentication >using Kerberos. Instead of adding general AAA mechanisms to DHCP, it makes sense to coordinate these services. A standard way to coordinate these should be the primary focus of this item in the DCHP charter. >On Thu, 15 Feb 2001, William A. Arbaugh wrote: >> >> With respect to wireless, either the people are going to run their >> wireless network completely open- i.e. no access control and no WEP. Or, >> they'll control the access in some way. In the former, there is no >> problem. DHCP works as it always has. In the latter, some form of >> out-of-band coordination is required to either get the WEP key, provide >> your MAC address, and/or get the network name (SSID). We're actually >> working on these issues at Univ. of Maryland as I speak. We've designed a >> mechanism for wireless access piggy backing on DHCP authentication, as >> well as support for WEP key mangement (which is badly needed). We have a >> rough prototype finished, but we need to polish it more. I expect we'll >> submit at least two drafts on a new authentication mechanism and a new >> option for WEP keys soon. We agree that authorization information such as SSID and WEP key should be provided for wireless hosts. The "out-of-band transfer" of this information could use existing AAA protocols from the AAA server to the access point, with the (802.1x) mechanism between the host and the access point. John From owner-dhcp-v4@bucknell.edu Fri Feb 16 16:55:22 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10366 for ; Fri, 16 Feb 2001 16:55:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GLrpL24468; Fri, 16 Feb 2001 16:53:51 -0500 (EST) Received: from styx.uwaterloo.ca (IDENT:root@styx.uwaterloo.ca [129.97.40.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GLrdL08928 for ; Fri, 16 Feb 2001 16:53:39 -0500 (EST) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id f1GLrZA13821; Fri, 16 Feb 2001 16:53:35 -0500 Date: Fri, 16 Feb 2001 16:53:35 -0500 (EST) From: Roop Mukherjee To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Why authenticate with DHCP? In-Reply-To: <4.1.20010216154744.00995540@diablo.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: bmukherj@styx.uwaterloo.ca Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The issue with the 802.1x proposal is as follows: On Fri, 16 Feb 2001, John Schnizlein wrote: > At 03:30 PM 02/16/2001 -0500, Roop Mukherjee wrote: > >... The AAA protocols are being used in the service provider networks > >for dial up (PPP) users. With new types of networks that do not adhere > >to the PPP scenarios DHCP may be a potential alternative. > > Yes, but another alternative that has gained some momentum already is > to use the same AAA protocols (RADIUS) from the network access point > that supports any of the IEEE 802 link-layer protocols. This is the > IEEE 802.1x approach. > > Following this alternative, the question becomes how to coordinate > between the port-level access control of 802.1x (and its AAA), > and DHCP. Coordination with DHCP could provide the sort of parameters > to the 802-connected host that PPP provides over dial-up lines. > Recall that AAA can interact with PPP to assign host IP addresses, etc. The suggestion above may be the answer if all the wireless networks we were trying to address were '802.1x' networks. For those networks that are 802.1x one may find value in trying to coordinate with the lower layers to interact with AAA. Also, given that the solution is specific to a link layer, a better forum for a proposal of that kind may be, 802.11's own security group. But it is expected that a whole plethora of devices, with different L1/L2s will run IP stacks. The solution then should be based on the commonality, not the diversity of the lower layers. Hence the suggestion that a general mechanism in the intial configuration protocol (DHCP for the purpose of this mailing list) may be key to using DHCP in future access networks. > > >My question then is what is needed for DHCP to be a viable alternative > >in commenrcial access networks? One possibility may be to add in > >general mechanisms to support AAA interactions, instead of just adding > >in a specific mechanism that performs cross domain authentication > >using Kerberos. > > Instead of adding general AAA mechanisms to DHCP, it makes sense to > coordinate these services. A standard way to coordinate these should > be the primary focus of this item in the DCHP charter. > -- Roop ________________________________________ From owner-dhcp-v4@bucknell.edu Fri Feb 16 17:25:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10716 for ; Fri, 16 Feb 2001 17:25:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1GMKaL13052; Fri, 16 Feb 2001 17:20:36 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1GMKSL10153 for ; Fri, 16 Feb 2001 17:20:28 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA10847; Fri, 16 Feb 2001 14:20:04 -0800 (PST) Message-Id: <4.1.20010216165913.00ad6280@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Feb 2001 17:19:09 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Why authenticate with DHCP? Cc: DHCPv4 discussion list In-Reply-To: References: <4.1.20010216154744.00995540@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 04:53 PM 02/16/2001 -0500, Roop Mukherjee wrote: >... >The suggestion above may be the answer if all the wireless networks >we were trying to address were '802.1x' networks. I know about IP over 802.11 wireless. What other wireless network needs dynamic IP address assignment? >...Also, given that the solution is specific to a link layer, >a better forum for a proposal of that kind may be, 802.11's own >security group. Are you suggesting that standardizing the interaction of DHCP with 802.1x be done in the IEEE instead of in the DHCP WG? >But it is expected that a whole plethora of devices, with different >L1/L2s will run IP stacks. The solution then should be based on the >commonality, not the diversity of the lower layers. PPP assigns host parmeters, including IP addresses, coordinated by AAA. DHCP could coordinate with AAA through 802.1x. One way of doing this is (indicated in the 802.1x annex D) AAA specifying the VLAN, which determines the giaddr based on the subnet of the VLAN. What other specific link layer you want to support? Recall that assigning IP addresses must be done at least partially at the link layer because these addresses are needed prior to the existence of any higher-layer communication. John From owner-dhcp-v4@bucknell.edu Sat Feb 17 12:13:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05434 for ; Sat, 17 Feb 2001 12:13:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1HH7SL25900; Sat, 17 Feb 2001 12:07:28 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1HH7ML31522 for ; Sat, 17 Feb 2001 12:07:22 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1HH10v31800; Sat, 17 Feb 2001 09:01:01 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Why authenticate with DHCP? Date: Sat, 17 Feb 2001 09:08:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.1.20010216154744.00995540@diablo.cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Yes, but another alternative that has gained some momentum already is >to use the same AAA protocols (RADIUS) from the network access point >that supports any of the IEEE 802 link-layer protocols. This is the >IEEE 802.1x approach. The 802.1X specification is available below: http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz In this approach, the VLAN can be determined dynamically and communicated to the switch via AAA. DHCP is used for configuration and address assignment. Assuming that a VLAN-aware network is in place, and that DHCP servers have interfaces on the appropriate VLANs, DHCP should continue to work as it always has. Since the 802.1X authenticator is assumed to be a layer 2 device, only layer 2 config (such as 802.11 SSID and WEP configuration) is carried out at that layer and AAA attributes such as Framed-IP-Address are not used. Since there isn't much overlap in functionality, it's possible in many cases to avoid having to coordinate DHCP with AAA. For details on AAA usage in 802.1X, see: http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-10.txt >We agree that authorization information such as SSID and WEP key should be >provided for wireless hosts. The "out-of-band transfer" of this information >could use existing AAA protocols from the AAA server to the access point, >with the (802.1x) mechanism between the host and the access point. WEP key assignment and SSID auto-config is already supported in the WEP v2.0 specification from 802.11 Task Group E: http://www.drizzle.com/~aboba/IEEE/1-18.zip http://www.drizzle.com/~aboba/IEEE/baseline.ppt.gz Next meeting of 802.11 TGe is February 23, 2001 in Seattle. From owner-dhcp-v6@bucknell.edu Mon Feb 19 12:10:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09382; Mon, 19 Feb 2001 12:10:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JH1vL07077; Mon, 19 Feb 2001 12:01:57 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JH1UL14931 for ; Mon, 19 Feb 2001 12:01:31 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1JH1Nr22747 for ; Mon, 19 Feb 2001 11:01:24 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1JH1NN25106 for ; Mon, 19 Feb 2001 11:01:23 -0600 (CST) Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Feb 19 11:01:21 2001 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <17BFYTRS>; Mon, 19 Feb 2001 11:01:22 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F645C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Questions about Release message Date: Mon, 19 Feb 2001 11:01:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A95.A6BD43C0" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09A95.A6BD43C0 Content-Type: text/plain; charset="iso-8859-1" Ralph, et al: Haven't seen any discussion about these questions ... >Can a client send an empty IA to release all addresses in the IA? It would be nice to support this as it provides an easy way for a client that might have used an IA before but has no record of what addresses it had. This way, on boot, it can release all without knowning what all was. >What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? My own feeling is that the IAs will need to be rather dynamic - some addresses will expire, others may be added as time goes on (to an IA). This may happen because of changes to the topology. For example, a single IA may start with one address. Later, as a renumbering event approaches, a new address is added (the new network number). Even later, the old address disappears from the IA as it has 'expired' (the lifetime on it has ended). I believe we also concluded that the client/server should always send the 'full' address details with the IA. This is needed for failover and also help that both client and server stay in sync. (The one exception may be on a release per above - empty IA to release all). >If the IA becomes empty - all addresses are released - can the server discard any record of the IA? Seems to me it should (just as much as it discards any record of the client). IPv6 address management is an interesting issue that hasn't really been discussed. In the IPv4 world the DHCP server remembers the client associated with an address (even after the client releases the address). I think the same might apply in IPv6 and thus the server really should remember the client information (including IA). That way, it can give the same address back again (just as in IPv4). Note that for DHCPv6, it might be possible for a server to have no memory other than the 'last assigned address'. Each time a client requests a 'new' lease, it increments the address. When renewals and rebindings arrive, the server simply allows the use of the address. With about 2^64 bits for addresses, it would take a LONG time before there would ever be even the potential for trouble (since that only happens when the addresses roll-over). Finally, sorry for the late posting regarding these questions. - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, February 02, 2001 12:54 AM To: DHCPv6 discussion list Subject: Questions about Release message There are some outstanding questions about Release messages in section 11.6.2 of the -16 DHCPv6 spec: What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? Can a client send an empty IA to release all addresses in the IA? If the IA becomes empty - all addresses are released - can the server discard any record of the IA? ------_=_NextPart_001_01C09A95.A6BD43C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions about Release message

Ralph, et al:

Haven't seen any discussion about these questions = ...

>Can a client send an empty IA to release all = addresses in the IA?

It would be nice to support this as it provides an = easy way for a client that might have used an IA before but has no = record of what addresses it had. This way, on boot, it can release all = without knowning what all was.

>What is the behavior of the server relative to a = ``partially released'' IA; i.e., an IA for which some but not all = addresses are released?

My own feeling is that the IAs will need to be rather = dynamic - some addresses will expire, others may be added as time goes = on (to an IA). This may happen because of changes to the topology. For = example, a single IA may start with one address. Later, as a = renumbering event approaches, a new address is added (the new network = number). Even later, the old address disappears from the IA as it has = 'expired' (the lifetime on it has ended).

I believe we also concluded that the client/server = should always send the 'full' address details with the IA. This is = needed for failover and also help that both client and server stay in = sync. (The one exception may be on a release per above - empty IA to = release all).

>If the IA becomes empty - all addresses are = released - can the server discard any record of the IA?

Seems to me it should (just as much as it discards = any record of the client). IPv6 address management is an interesting = issue that hasn't really been discussed. In the IPv4 world the DHCP = server remembers the client associated with an address (even after the = client releases the address). I think the same might apply in IPv6 and = thus the server really should remember the client information = (including IA). That way, it can give the same address back again (just = as in IPv4).

Note that for DHCPv6, it might be possible for a = server to have no memory other than the 'last assigned address'. Each = time a client requests a 'new' lease, it increments the address. When = renewals and rebindings arrive, the server simply allows the use of the = address. With about 2^64 bits for addresses, it would take a LONG time = before there would ever be even the potential for trouble (since that = only happens when the addresses roll-over).


Finally, sorry for the late posting regarding these = questions.

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, February 02, 2001 12:54 AM
To: DHCPv6 discussion list
Subject: Questions about Release message


There are some outstanding questions about Release = messages in section
11.6.2 of the -16 DHCPv6 spec:

What is the behavior of the server relative to a = ``partially
released'' IA; i.e., an IA for which some but not = all addresses are
released?

Can a client send an empty IA to release all = addresses in the IA?

If the IA becomes empty - all addresses are released = - can the server
discard any record of the IA?

------_=_NextPart_001_01C09A95.A6BD43C0-- From owner-dhcp-v6@bucknell.edu Mon Feb 19 12:21:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09693; Mon, 19 Feb 2001 12:21:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JHLJL28939; Mon, 19 Feb 2001 12:21:19 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JHLEL11971 for ; Mon, 19 Feb 2001 12:21:14 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1JHLBr07144 for ; Mon, 19 Feb 2001 11:21:11 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1JHLBN03490 for ; Mon, 19 Feb 2001 11:21:11 -0600 (CST) Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Feb 19 11:20:56 2001 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <17BFYVQS>; Mon, 19 Feb 2001 11:20:57 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F645D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Questions about Release message Date: Mon, 19 Feb 2001 11:22:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A98.7FD6BD60" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09A98.7FD6BD60 Content-Type: text/plain; charset="iso-8859-1" BTW: What, if any, recommendations should be given in the DHCPv6 specification regarding assignment/generation of addresses? Should the DHCPv6 server assign addresses using the EUI-64 identifier of the client? Should the DHCPv6 server NOT assign these addresses but have some other method of generating addresses? If one assumes that a given network prefix will either be all auto-configured or all stateful configuration, the stateful configuration is really free to do what it wants. However, if one assumes that there could be both methods (perhaps not at the same time), one might want to make sure that stateful configuration doesn't use EUI-64 identifiers for the low 64-bits of the address. Otherwise, problems could exist when switching configuration modes (Duplicate Address Detection will help to eliminate potential problems). Of course, using EUI-64 identifiers won't work if a client has multiple IAs (wants multiple addresses) on a single network prefix. Perhaps some of this is addressed in an IPv6 addressing structure RFC or ID? - Bernie Volz Ericsson -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Monday, February 19, 2001 12:02 PM To: DHCPv6 discussion list Subject: RE: Questions about Release message Ralph, et al: Haven't seen any discussion about these questions ... >Can a client send an empty IA to release all addresses in the IA? It would be nice to support this as it provides an easy way for a client that might have used an IA before but has no record of what addresses it had. This way, on boot, it can release all without knowning what all was. >What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? My own feeling is that the IAs will need to be rather dynamic - some addresses will expire, others may be added as time goes on (to an IA). This may happen because of changes to the topology. For example, a single IA may start with one address. Later, as a renumbering event approaches, a new address is added (the new network number). Even later, the old address disappears from the IA as it has 'expired' (the lifetime on it has ended). I believe we also concluded that the client/server should always send the 'full' address details with the IA. This is needed for failover and also help that both client and server stay in sync. (The one exception may be on a release per above - empty IA to release all). >If the IA becomes empty - all addresses are released - can the server discard any record of the IA? Seems to me it should (just as much as it discards any record of the client). IPv6 address management is an interesting issue that hasn't really been discussed. In the IPv4 world the DHCP server remembers the client associated with an address (even after the client releases the address). I think the same might apply in IPv6 and thus the server really should remember the client information (including IA). That way, it can give the same address back again (just as in IPv4). Note that for DHCPv6, it might be possible for a server to have no memory other than the 'last assigned address'. Each time a client requests a 'new' lease, it increments the address. When renewals and rebindings arrive, the server simply allows the use of the address. With about 2^64 bits for addresses, it would take a LONG time before there would ever be even the potential for trouble (since that only happens when the addresses roll-over). Finally, sorry for the late posting regarding these questions. - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [ mailto:rdroms@cisco.com ] Sent: Friday, February 02, 2001 12:54 AM To: DHCPv6 discussion list Subject: Questions about Release message There are some outstanding questions about Release messages in section 11.6.2 of the -16 DHCPv6 spec: What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? Can a client send an empty IA to release all addresses in the IA? If the IA becomes empty - all addresses are released - can the server discard any record of the IA? ------_=_NextPart_001_01C09A98.7FD6BD60 Content-Type: text/html; charset="iso-8859-1" RE: Questions about Release message
BTW: What, if any, recommendations should be given in the DHCPv6 specification regarding assignment/generation of addresses? Should the DHCPv6 server assign addresses using the EUI-64 identifier of the client? Should the DHCPv6 server NOT assign these addresses but have some other method of generating addresses?
 
If one assumes that a given network prefix will either be all auto-configured or all stateful configuration, the stateful configuration is really free to do what it wants. However, if one assumes that there could be both methods (perhaps not at the same time), one might want to make sure that stateful configuration doesn't use EUI-64 identifiers for the low 64-bits of the address. Otherwise, problems could exist when switching configuration modes (Duplicate Address Detection will help to eliminate potential problems).
 
Of course, using EUI-64 identifiers won't work if a client has multiple IAs (wants multiple addresses) on a single network prefix.
 
Perhaps some of this is addressed in an IPv6 addressing structure RFC or ID?
 
- Bernie Volz
  Ericsson
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Monday, February 19, 2001 12:02 PM
To: DHCPv6 discussion list
Subject: RE: Questions about Release message

Ralph, et al:

Haven't seen any discussion about these questions ...

>Can a client send an empty IA to release all addresses in the IA?

It would be nice to support this as it provides an easy way for a client that might have used an IA before but has no record of what addresses it had. This way, on boot, it can release all without knowning what all was.

>What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released?

My own feeling is that the IAs will need to be rather dynamic - some addresses will expire, others may be added as time goes on (to an IA). This may happen because of changes to the topology. For example, a single IA may start with one address. Later, as a renumbering event approaches, a new address is added (the new network number). Even later, the old address disappears from the IA as it has 'expired' (the lifetime on it has ended).

I believe we also concluded that the client/server should always send the 'full' address details with the IA. This is needed for failover and also help that both client and server stay in sync. (The one exception may be on a release per above - empty IA to release all).

>If the IA becomes empty - all addresses are released - can the server discard any record of the IA?

Seems to me it should (just as much as it discards any record of the client). IPv6 address management is an interesting issue that hasn't really been discussed. In the IPv4 world the DHCP server remembers the client associated with an address (even after the client releases the address). I think the same might apply in IPv6 and thus the server really should remember the client information (including IA). That way, it can give the same address back again (just as in IPv4).

Note that for DHCPv6, it might be possible for a server to have no memory other than the 'last assigned address'. Each time a client requests a 'new' lease, it increments the address. When renewals and rebindings arrive, the server simply allows the use of the address. With about 2^64 bits for addresses, it would take a LONG time before there would ever be even the potential for trouble (since that only happens when the addresses roll-over).


Finally, sorry for the late posting regarding these questions.

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, February 02, 2001 12:54 AM
To: DHCPv6 discussion list
Subject: Questions about Release message


There are some outstanding questions about Release messages in section
11.6.2 of the -16 DHCPv6 spec:

What is the behavior of the server relative to a ``partially
released'' IA; i.e., an IA for which some but not all addresses are
released?

Can a client send an empty IA to release all addresses in the IA?

If the IA becomes empty - all addresses are released - can the server
discard any record of the IA?

------_=_NextPart_001_01C09A98.7FD6BD60-- From owner-dhcp-v6@bucknell.edu Mon Feb 19 13:04:14 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10425; Mon, 19 Feb 2001 13:04:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JHx7L14142; Mon, 19 Feb 2001 12:59:07 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JHwrL08063 for ; Mon, 19 Feb 2001 12:58:53 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 09:56:58 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 09:56:05 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 09:56:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 content-class: urn:content-classes:message Subject: RE: Questions about Release message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A9D.3A48BAF7" Date: Mon, 19 Feb 2001 09:56:04 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A688C5756@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Questions about Release message Thread-Index: AcCamLnxYcKPXXH4TUOGTlvWumfCPwAA9X8w From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 19 Feb 2001 17:56:04.0801 (UTC) FILETIME=[3A7A4B10:01C09A9D] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09A9D.3A48BAF7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the ability for a client to get multiple IP addresses from a server is relevant in IPv6. ( either by using multiple IAs or by some other method. ) The number of IP addresses available is no longer a constraint and I can think of some apps that would like to take advantage of this. It is even possible that new apps/protocols will be developed to make use of the abundant supply of IP addresses. =20 thx =20 =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Monday, February 19, 2001 9:22 AM To: DHCPv6 discussion list Subject: RE: Questions about Release message BTW: What, if any, recommendations should be given in the DHCPv6 specification regarding assignment/generation of addresses? Should the DHCPv6 server assign addresses using the EUI-64 identifier of the client? Should the DHCPv6 server NOT assign these addresses but have some other method of generating addresses? =20 If one assumes that a given network prefix will either be all auto-configured or all stateful configuration, the stateful configuration is really free to do what it wants. However, if one assumes that there could be both methods (perhaps not at the same time), one might want to make sure that stateful configuration doesn't use EUI-64 identifiers for the low 64-bits of the address. Otherwise, problems could exist when switching configuration modes (Duplicate Address Detection will help to eliminate potential problems). =20 Of course, using EUI-64 identifiers won't work if a client has multiple IAs (wants multiple addresses) on a single network prefix. =20 Perhaps some of this is addressed in an IPv6 addressing structure RFC or ID? =20 - Bernie Volz Ericsson -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Monday, February 19, 2001 12:02 PM To: DHCPv6 discussion list Subject: RE: Questions about Release message Ralph, et al:=20 Haven't seen any discussion about these questions ...=20 >Can a client send an empty IA to release all addresses in the IA?=20 It would be nice to support this as it provides an easy way for a client that might have used an IA before but has no record of what addresses it had. This way, on boot, it can release all without knowning what all was. >What is the behavior of the server relative to a ``partially released'' IA; i.e., an IA for which some but not all addresses are released? My own feeling is that the IAs will need to be rather dynamic - some addresses will expire, others may be added as time goes on (to an IA). This may happen because of changes to the topology. For example, a single IA may start with one address. Later, as a renumbering event approaches, a new address is added (the new network number). Even later, the old address disappears from the IA as it has 'expired' (the lifetime on it has ended). I believe we also concluded that the client/server should always send the 'full' address details with the IA. This is needed for failover and also help that both client and server stay in sync. (The one exception may be on a release per above - empty IA to release all). >If the IA becomes empty - all addresses are released - can the server discard any record of the IA?=20 Seems to me it should (just as much as it discards any record of the client). IPv6 address management is an interesting issue that hasn't really been discussed. In the IPv4 world the DHCP server remembers the client associated with an address (even after the client releases the address). I think the same might apply in IPv6 and thus the server really should remember the client information (including IA). That way, it can give the same address back again (just as in IPv4). Note that for DHCPv6, it might be possible for a server to have no memory other than the 'last assigned address'. Each time a client requests a 'new' lease, it increments the address. When renewals and rebindings arrive, the server simply allows the use of the address. With about 2^64 bits for addresses, it would take a LONG time before there would ever be even the potential for trouble (since that only happens when the addresses roll-over). Finally, sorry for the late posting regarding these questions.=20 - Bernie Volz=20 Ericsson=20 -----Original Message-----=20 From: Ralph Droms [ mailto:rdroms@cisco.com]=20 Sent: Friday, February 02, 2001 12:54 AM=20 To: DHCPv6 discussion list=20 Subject: Questions about Release message=20 There are some outstanding questions about Release messages in section=20 11.6.2 of the -16 DHCPv6 spec:=20 What is the behavior of the server relative to a ``partially=20 released'' IA; i.e., an IA for which some but not all addresses are=20 released?=20 Can a client send an empty IA to release all addresses in the IA?=20 If the IA becomes empty - all addresses are released - can the server=20 discard any record of the IA?=20 ------_=_NextPart_001_01C09A9D.3A48BAF7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions about Release message
I=20 think the ability for a client to get multiple IP addresses from a = server is=20 relevant in IPv6. ( either by using multiple IAs or by some other = method. )=20 The number of IP addresses available is no longer a constraint and I can = think=20 of some apps that would like to take advantage of this. It is even = possible that=20 new apps/protocols will be developed to make use of the abundant supply = of IP=20 addresses.
 
thx
 
 
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Monday, February = 19, 2001=20 9:22 AM
To: DHCPv6 discussion list
Subject: RE: = Questions=20 about Release message

BTW:=20 What, if any, recommendations should be given in the DHCPv6 = specification=20 regarding assignment/generation of addresses? Should the DHCPv6 server = assign=20 addresses using the EUI-64 identifier of the client? Should the DHCPv6 = server=20 NOT assign these addresses but have some other method = of generating=20 addresses?
 
If=20 one assumes that a given network prefix will either be all = auto-configured or=20 all stateful configuration, the stateful configuration is really free = to do=20 what it wants. However, if one assumes that there could be both = methods=20 (perhaps not at the same time), one might want to make sure that = stateful=20 configuration doesn't use EUI-64 identifiers for the low 64-bits of = the=20 address. Otherwise, problems could exist when switching configuration = modes=20 (Duplicate Address Detection will help to eliminate potential=20 problems).
 
Of=20 course, using EUI-64 identifiers won't work if a client has multiple = IAs=20 (wants multiple addresses) on a single network = prefix.
 
Perhaps some of this is addressed in an = IPv6=20 addressing structure RFC or ID?
 
-=20 Bernie Volz
  Ericsson
-----Original Message-----
From: Bernie Volz = (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Monday, = February 19,=20 2001 12:02 PM
To: DHCPv6 discussion = list
Subject: RE:=20 Questions about Release message

Ralph, et al:

Haven't seen any discussion about these questions = ...=20

>Can a client send an empty IA to release all = addresses=20 in the IA?

It would be nice to support this as it provides an = easy way=20 for a client that might have used an IA before but has no record of = what=20 addresses it had. This way, on boot, it can release all without = knowning=20 what all was.

>What is the behavior of the server relative to = a=20 ``partially released'' IA; i.e., an IA for which some but not all = addresses=20 are released?

My own feeling is that the IAs will need to be = rather=20 dynamic - some addresses will expire, others may be added as time = goes on=20 (to an IA). This may happen because of changes to the topology. For = example,=20 a single IA may start with one address. Later, as a renumbering = event=20 approaches, a new address is added (the new network number). Even = later, the=20 old address disappears from the IA as it has 'expired' (the lifetime = on it=20 has ended).

I believe we also concluded that the client/server = should=20 always send the 'full' address details with the IA. This is needed = for=20 failover and also help that both client and server stay in sync. = (The one=20 exception may be on a release per above - empty IA to release=20 all).

>If the IA becomes empty - all addresses are = released -=20 can the server discard any record of the IA?

Seems to me it should (just as much as it discards = any=20 record of the client). IPv6 address management is an interesting = issue that=20 hasn't really been discussed. In the IPv4 world the DHCP server = remembers=20 the client associated with an address (even after the client = releases the=20 address). I think the same might apply in IPv6 and thus the server = really=20 should remember the client information (including IA). That way, it = can give=20 the same address back again (just as in IPv4).

Note that for DHCPv6, it might be possible for a = server to=20 have no memory other than the 'last assigned address'. Each time a = client=20 requests a 'new' lease, it increments the address. When renewals and = rebindings arrive, the server simply allows the use of the address. = With=20 about 2^64 bits for addresses, it would take a LONG time before = there would=20 ever be even the potential for trouble (since that only happens when = the=20 addresses roll-over).


Finally, sorry for the late posting regarding = these=20 questions.

- Bernie Volz
  = Ericsson=20

-----Original Message-----
From:=20 Ralph Droms [mailto:rdroms@cisco.com] =
Sent: Friday, February 02, 2001 12:54 AM
To:=20 DHCPv6 discussion list
Subject: Questions = about=20 Release message


There are some outstanding questions about Release = messages=20 in section
11.6.2 of the -16 DHCPv6 = spec:=20

What is the behavior of the server relative to a=20 ``partially
released'' IA; i.e., an IA for = which=20 some but not all addresses are
released?

Can a client send an empty IA to release all = addresses in=20 the IA?

If the IA becomes empty - all addresses are = released - can=20 the server
discard any record of the = IA?=20

------_=_NextPart_001_01C09A9D.3A48BAF7-- From owner-dhcp-v6@bucknell.edu Mon Feb 19 13:46:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11496; Mon, 19 Feb 2001 13:46:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JIbiL01044; Mon, 19 Feb 2001 13:37:44 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JIbLL02218 for ; Mon, 19 Feb 2001 13:37:22 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27601; Mon, 19 Feb 2001 10:37:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1JIb2q02333; Mon, 19 Feb 2001 10:37:02 -0800 X-mProtect: Mon, 19 Feb 2001 10:37:02 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdtyg5aJ; Mon, 19 Feb 2001 10:36:53 PST Message-ID: <3A91669E.4645C644@iprg.nokia.com> Date: Mon, 19 Feb 2001 10:31:59 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: dhcp-v6@bucknell.edu Subject: Re: Questions about Release message References: <78B1387745A15C46A7A727F2670D4A688C5756@DF-MILO.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, Well, good luck getting them. I hope you succeed. Of course, you have no way to predict when or where the application wants to run, so you can't preconfigure clients for application needs. This is a good thing in my opinion, and yet the DHCPv6 specification may never support that feature again. Regards, Charlie P. Thirumalesh Bhat wrote: > I think the ability for a client to get multiple IP addresses from a > server is relevant in IPv6. ( either by using multiple IAs or by some > other method. ) The number of IP addresses available is no longer a > constraint and I can think of some apps that would like to take > advantage of this. It is even possible that new apps/protocols will be > developed to make use of the abundant supply of IP addresses.thx > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > > Sent: Monday, February 19, 2001 9:22 AM > To: DHCPv6 discussion list > Subject: RE: Questions about Release message > > BTW: What, if any, recommendations should be given in the > DHCPv6 specification regarding assignment/generation of > addresses? Should the DHCPv6 server assign addresses using > the EUI-64 identifier of the client? Should the DHCPv6 > server NOT assign these addresses but have some other method > of generating addresses?If one assumes that a given network > prefix will either be all auto-configured or all stateful > configuration, the stateful configuration is really free to > do what it wants. However, if one assumes that there could > be both methods (perhaps not at the same time), one might > want to make sure that stateful configuration doesn't use > EUI-64 identifiers for the low 64-bits of the address. > Otherwise, problems could exist when switching configuration > modes (Duplicate Address Detection will help to eliminate > potential problems).Of course, using EUI-64 identifiers > won't work if a client has multiple IAs (wants multiple > addresses) on a single network prefix. Perhaps some of this > is addressed in an IPv6 addressing structure RFC or ID?- > Bernie Volz Ericsson > > -----Original Message----- > From: Bernie Volz (EUD) > [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Monday, February 19, 2001 12:02 PM > To: DHCPv6 discussion list > Subject: RE: Questions about Release message > > Ralph, et al: > > Haven't seen any discussion about these questions > ... > > >Can a client send an empty IA to release all > addresses in the IA? > > It would be nice to support this as it provides an > easy way for a client that might have used an IA > before but has no record of what addresses it had. > This way, on boot, it can release all without > knowning what all was. > > >What is the behavior of the server relative to a > ``partially released'' IA; i.e., an IA for which > some but not all addresses are released? > > My own feeling is that the IAs will need to be > rather dynamic - some addresses will expire, > others may be added as time goes on (to an IA). > This may happen because of changes to the > topology. For example, a single IA may start with > one address. Later, as a renumbering event > approaches, a new address is added (the new > network number). Even later, the old address > disappears from the IA as it has 'expired' (the > lifetime on it has ended). > > I believe we also concluded that the client/server > should always send the 'full' address details with > the IA. This is needed for failover and also help > that both client and server stay in sync. (The one > exception may be on a release per above - empty IA > to release all). > > >If the IA becomes empty - all addresses are > released - can the server discard any record of > the IA? > > Seems to me it should (just as much as it discards > any record of the client). IPv6 address management > is an interesting issue that hasn't really been > discussed. In the IPv4 world the DHCP server > remembers the client associated with an address > (even after the client releases the address). I > think the same might apply in IPv6 and thus the > server really should remember the client > information (including IA). That way, it can give > the same address back again (just as in IPv4). > > Note that for DHCPv6, it might be possible for a > server to have no memory other than the 'last > assigned address'. Each time a client requests a > 'new' lease, it increments the address. When > renewals and rebindings arrive, the server simply > allows the use of the address. With about 2^64 > bits for addresses, it would take a LONG time > before there would ever be even the potential for > trouble (since that only happens when the > addresses roll-over). > > Finally, sorry for the late posting regarding > these questions. > > - Bernie Volz > Ericsson > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, February 02, 2001 12:54 AM > To: DHCPv6 discussion list > Subject: Questions about Release message > > There are some outstanding questions about Release > messages in section > 11.6.2 of the -16 DHCPv6 spec: > > What is the behavior of the server relative to a > ``partially > released'' IA; i.e., an IA for which some but not > all addresses are > released? > > Can a client send an empty IA to release all > addresses in the IA? > > If the IA becomes empty - all addresses are > released - can the server > discard any record of the IA? > From owner-dhcp-v6@bucknell.edu Mon Feb 19 14:25:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12583; Mon, 19 Feb 2001 14:25:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JJK6L21791; Mon, 19 Feb 2001 14:20:06 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JJJpL22716 for ; Mon, 19 Feb 2001 14:19:51 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1JJJor29274 for ; Mon, 19 Feb 2001 13:19:50 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1JJJoO22183 for ; Mon, 19 Feb 2001 13:19:50 -0600 (CST) Received: FROM eamrcnt751.exu.ericsson.se BY eamrcnt749 ; Mon Feb 19 13:21:08 2001 -0600 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <17BGFKDD>; Mon, 19 Feb 2001 13:19:48 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F645F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Advertising prefixes Date: Mon, 19 Feb 2001 13:21:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09AA9.1B5ACD20" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09AA9.1B5ACD20 Content-Type: text/plain; charset="iso-8859-1" Ralph: I don't suppose there is any easy way to defer this for later consideration - be nice to focus on the core functionality now. Perhaps one solution is to send these prefix advertisements in a new option (not use the Identity association option). Though there likely would be some backwards compatibility issues. One other thought is why not just have the server do this work (ie, assign the address rather than advertise the prefix) rather than having the client (and client's IPv6 stack) handle yet one more thing and one more type of address. Finally, if you use the Identity association option, what implication does the lease time have on these prefix advertisements? What if all the Identity association option contained was prefix advertisements (no addresses)? - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 07, 2001 8:44 AM To: DHCPv6 discussion list Subject: Advertising prefixes Prior to the -16 rev of the DHCPv6 draft, we decided to limit DHCPv6 to the assignment of addresses and eliminated the advertisement of prefixes. After thinking about some address management scenarios, it seems to me that it might be useful to combine DHCP and stateless autoconfiguration to provide host-specific prefix configuration without individual address management. My proposal is to allow a DHCP server to assign prefixes as well as addresses in an IA to a client. For example, the prefix might be carried in an IA as an address with all 0s in the low order bits (those bits not included in the prefix). The client would then apply stateless autoconfig to those DHCP-assigned prefixes. The client might also use the DHCP-assigned prefixes to generate anonymous addresses. DHCP assignment of prefixes would be useful in "managed access" networks, where not all of the prefixes assigned to a link are to be used by every client on that link. - Ralph ------_=_NextPart_001_01C09AA9.1B5ACD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Advertising prefixes

Ralph:

I don't suppose there is any easy way to defer this = for later consideration - be nice to focus on the core functionality = now. Perhaps one solution is to send these prefix advertisements in a = new option (not use the Identity association option). Though there = likely would be some backwards compatibility issues.

One other thought is why not just have the server do = this work (ie, assign the address rather than advertise the prefix) = rather than having the client (and client's IPv6 stack) handle yet one = more thing and one more type of address.

Finally, if you use the Identity association option, = what implication does the lease time have on these prefix = advertisements? What if all the Identity association option contained = was prefix advertisements (no addresses)?

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 07, 2001 8:44 AM
To: DHCPv6 discussion list
Subject: Advertising prefixes


Prior to the -16 rev of the DHCPv6 draft, we decided = to limit DHCPv6 to the
assignment of addresses and eliminated the = advertisement of
prefixes.  After thinking about some address = management scenarios, it seems
to me that it might be useful to combine DHCP and = stateless
autoconfiguration to provide host-specific prefix = configuration without
individual address management.

My proposal is to allow a DHCP server to assign = prefixes as well as
addresses in an IA to a client.  For example, = the prefix might be carried
in an IA as an address with all 0s in the low order = bits (those bits not
included in the prefix).  The client would then = apply stateless autoconfig
to those DHCP-assigned prefixes.  The client = might also use the
DHCP-assigned prefixes to generate anonymous = addresses.

DHCP assignment of prefixes would be useful in = "managed access" networks,
where not all of the prefixes assigned to a link are = to be used by every
client on that link.

- Ralph

------_=_NextPart_001_01C09AA9.1B5ACD20-- From owner-dhcp-v6@bucknell.edu Mon Feb 19 14:26:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12621; Mon, 19 Feb 2001 14:26:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JJKlL28057; Mon, 19 Feb 2001 14:20:47 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JJKZL24177 for ; Mon, 19 Feb 2001 14:20:35 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1JJKWr00009 for ; Mon, 19 Feb 2001 13:20:32 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1JJKWO22613 for ; Mon, 19 Feb 2001 13:20:32 -0600 (CST) Received: FROM eamrcnt751.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Feb 19 13:21:50 2001 -0600 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <17BGFKFT>; Mon, 19 Feb 2001 13:20:30 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6460@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Input and teleconference Date: Mon, 19 Feb 2001 13:21:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09AA9.34493F60" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09AA9.34493F60 Content-Type: text/plain; charset="iso-8859-1" Ralph ... what's the status of the draft? Any update? - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 07, 2001 8:23 AM To: DHCPv6 discussion list Subject: Input and teleconference I've only received three responses to my announcement of the next DHCPv6 teleconference. Because I don't yet have the next rev of the draft finished and because of that apparent lack of interest, I've decided to postpone the teleconference until I have a better sense of when the next rev will be finished. We need to have full WG participation in the discussion on a couple of issues raised at the San Diego WG meeting. I've started discussion on multicast reconfiguration and IA naming, but haven't seen many message in either thread. We also need to discuss how DHCPv6 will interact with anonymous addresses, which I will kick off in a separate message. I need this input before I can finish revving the draft. - Ralph ------_=_NextPart_001_01C09AA9.34493F60 Content-Type: text/html; charset="iso-8859-1" RE: Input and teleconference

Ralph ... what's the status of the draft? Any update?

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 07, 2001 8:23 AM
To: DHCPv6 discussion list
Subject: Input and teleconference


I've only received three responses to my announcement of the next DHCPv6
teleconference.  Because I don't yet have the next rev of the draft
finished and because of that apparent lack of interest, I've decided to
postpone the teleconference until I have a better sense of when the next
rev will be finished.

We need to have full WG participation in the discussion on a couple of
issues raised at the San Diego WG meeting.  I've started discussion on
multicast reconfiguration and IA naming, but haven't seen many message in
either thread.  We also need to discuss how DHCPv6 will interact with
anonymous addresses, which I will kick off in a separate message.  I need
this input before I can finish revving the draft.

- Ralph

------_=_NextPart_001_01C09AA9.34493F60-- From owner-dhcp-v6@bucknell.edu Mon Feb 19 16:12:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14780; Mon, 19 Feb 2001 16:12:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1JL7mL06832; Mon, 19 Feb 2001 16:07:48 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1JL7XL07685 for ; Mon, 19 Feb 2001 16:07:33 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1JL7Vr05997 for ; Mon, 19 Feb 2001 15:07:31 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1JL7VO00182 for ; Mon, 19 Feb 2001 15:07:31 -0600 (CST) Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Feb 19 15:08:49 2001 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <17BFZJ7G>; Mon, 19 Feb 2001 15:07:29 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6464@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Issue from San Diego IETF - temporary addresses Date: Mon, 19 Feb 2001 15:08:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09AB8.27067B10" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09AB8.27067B10 Content-Type: text/plain; charset="iso-8859-1" >From the San Diego IETF minutes: * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. Shouldn't this say "How can the DHCP client indicate to the server which addreses are to be "temporary" and which are "permanent"? It is after all the client that might have an understanding of how long the address is desired. As the client will send an "Identity Association Option" to request address(es), couldn't this simply be communicated via a lease request time? Though there probably is no good field to store this in. And, then we should perhaps ask WHY DOES THE SERVER CARE? If the client wants a short lease, the server simply grants it the address(es) for however long the server policy dictates. If the client doesn't want to use the address after a period of time, it is ALWAYS able to RELEASE it whenever it is done. Even if it doesn't release it but instead simply lets it expire, what's the harm? There should be plenty of addresses available in IPv6. Of course, the requirements document might help answer why Thomas feels there is a need to have a mechanism to explicitly request these temporary addresses. Perhaps the reason for the 'temporary' addresses is that they are supposed to be 'random' instead of based on the EUI-64 identifier of the client; but as a previous message pointed out nothing has been said as to how a DHCP server will assign addresses. A question ... should the "Identity Association Option" that the client sends the server be identical to the one that the server sends the client? Or, might it be better to have two options - one which is sent by the client and another that is sent by the server? The one sent by the server is what's specified in the -16 draft. A different one might be specified for the cleint to send (such as without T1, T2, and lifetimes, etc). Perhaps this would also make it easier to add in a field for the client to request the length of the desired lease time. - Bernie Volz Ericsson ------_=_NextPart_001_01C09AB8.27067B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Issue from San Diego IETF - temporary addresses

From the San Diego IETF = minutes:

* Narten also raised issue of = interaction between DHCP and temporary addresses. DHCP server can = provide temporary addresses by assigning addresses with short = lifetimes. However, there will be an API through which an application = can request a temporary address. How can the DHCP server indicate to = the client which addresses are to be "temporary" and which = are "permanent"? Narten thinks IESG will bounce anything that = doesn't deal with temporary addresses. He will develop requirements doc = so WG can develop solution.

Shouldn't this say "How can the = DHCP client indicate to the server which addreses are to be = "temporary" and which are "permanent"? It is after = all the client that might have an understanding of how long the address = is desired.

As the client will send an = "Identity Association Option" to request address(es), = couldn't this simply be communicated via a lease request time? Though = there probably is no good field to store this in.

And, then we should perhaps ask WHY = DOES THE SERVER CARE? If the client wants a short lease, the server = simply grants it the address(es) for however long the server policy = dictates. If the client doesn't want to use the address after a period = of time, it is ALWAYS able to RELEASE it whenever it is done. Even if = it doesn't release it but instead simply lets it expire, what's the = harm? There should be plenty of addresses available in IPv6.

Of course, the requirements document = might help answer why Thomas feels there is a need to have a mechanism = to explicitly request these temporary addresses. Perhaps the reason for = the 'temporary' addresses is that they are supposed to be 'random' = instead of based on the EUI-64 identifier of the client; but as a = previous message pointed out nothing has been said as to how a DHCP = server will assign addresses.


A question ... should the = "Identity Association Option" that the client sends the = server be identical to the one that the server sends the client? Or, = might it be better to have two options - one which is sent by the = client and another that is sent by the server? The one sent by the = server is what's specified in the -16 draft. A different one might be = specified for the cleint to send (such as without T1, T2, and = lifetimes, etc). Perhaps this would also make it easier to add in a = field for the client to request the length of the desired lease = time.

- Bernie Volz
  Ericsson


------_=_NextPart_001_01C09AB8.27067B10-- From owner-dhcp-v6@bucknell.edu Tue Feb 20 14:12:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21195; Tue, 20 Feb 2001 14:12:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1KJ3cL03503; Tue, 20 Feb 2001 14:03:38 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1KJ2uL17240 for ; Tue, 20 Feb 2001 14:02:58 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1KJ2kg19067 for ; Tue, 20 Feb 2001 13:02:50 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 20 Feb 2001 13:02:47 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 20 Feb 2001 13:02:47 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: Updated DSTM Draft Date: Tue, 20 Feb 2001 13:02:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09B6F.B5E9AFC0" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C09B6F.B5E9AFC0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B6F.B5E9AFC0" ------_=_NextPart_001_01C09B6F.B5E9AFC0 Content-Type: text/plain; charset="iso-8859-1" You might want to check this out and see the new dstm dhcpv6 option...... /jim A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Generation Transition Working Group of the IETF. Title : Dual Stack Transition Mechanism (DSTM) Author(s) : J. Bound, L. Toutain, F. Dupont, H. Afifi, A. Durand Filename : draft-ietf-ngtrans-dstm-04.txt Pages : 20 Date : 14-Feb-01 ------_=_NextPart_001_01C09B6F.B5E9AFC0 Content-Type: text/html; charset="iso-8859-1" Issue from San Diego IETF - temporary addresses

You might want to check this out and see the new dstm dhcpv6 option......

/jim

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Next Generation Transition Working Group of the IETF.

Title : Dual Stack Transition Mechanism (DSTM)

Author(s) : J. Bound, L. Toutain, F. Dupont, H. Afifi, A. Durand

Filename : draft-ietf-ngtrans-dstm-04.txt

Pages : 20

Date : 14-Feb-01

------_=_NextPart_001_01C09B6F.B5E9AFC0-- ------_=_NextPart_000_01C09B6F.B5E9AFC0 Content-Type: message/rfc822 Content-Description: (ngtrans) I-D ACTION:draft-ietf-ngtrans-dstm-04.txt Message-ID: <200102151147.GAA12905@ietf.org> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: ngtrans@sunroof.eng.sun.com Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-dstm-04.txt Date: Thu, 15 Feb 2001 05:47:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C09B6F.B5E9AFC0" ------_=_NextPart_002_01C09B6F.B5E9AFC0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C09B6F.B5E9AFC0" ------_=_NextPart_003_01C09B6F.B5E9AFC0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Generation Transition Working Group of the IETF. Title : Dual Stack Transition Mechanism (DSTM) Author(s) : J. Bound, L. Toutain, F. Dupont, H. Afifi, A. Durand Filename : draft-ietf-ngtrans-dstm-04.txt Pages : 20 Date : 14-Feb-01 The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4, within an IPv6 Network. Nodes will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition Mechanism (DSTM) provides a method to assign temporary Global IPv4 Addresses to IPv6/IPv4 nodes over a native IPv6 Network, use of dynamic tunnels within an IPv6 Network to carry IPv4 traffic, and a defined set of processes and architecture for the supporting infrastructure required for this transition mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.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-ngtrans-dstm-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ngtrans-dstm-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_003_01C09B6F.B5E9AFC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable (ngtrans) I-D ACTION:draft-ietf-ngtrans-dstm-04.txt

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Next Generation = Transition Working Group of the IETF.

        Title           : = Dual Stack Transition Mechanism (DSTM)
        Author(s)       : J. Bound, L. = Toutain, F. Dupont, H. Afifi, A. Durand
        Filename        : = draft-ietf-ngtrans-dstm-04.txt
        Pages           : = 20
        Date    =         : 14-Feb-01
       =20
The initial deployment of IPv6 will require a = tightly coupled use of
IPv4 addresses to support the interoperation of IPv6 = and IPv4, within
an IPv6 Network.  Nodes will still need to = communicate with IPv4
nodes that do not have a dual IP layer supporting = both IPv4 and IPv6.
The Dual Stack Transition Mechanism (DSTM) provides = a method to
assign temporary Global IPv4 Addresses to IPv6/IPv4 = nodes over a
native IPv6 Network, use of dynamic tunnels within = an IPv6 Network to
carry IPv4 traffic, and a defined set of processes = and architecture
for the supporting infrastructure required for this = transition
mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans= -dstm-04.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-ngtrans-dstm-04.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-ngtrans-dstm-04.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_003_01C09B6F.B5E9AFC0-- ------_=_NextPart_002_01C09B6F.B5E9AFC0 Content-Type: message/rfc822 To: Subject: Date: Tue, 20 Feb 2001 13:02:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01C09B6F.B5E9AFC0" ------_=_NextPart_004_01C09B6F.B5E9AFC0 Content-Type: multipart/alternative; boundary="----_=_NextPart_005_01C09B6F.B5E9AFC0" ------_=_NextPart_005_01C09B6F.B5E9AFC0 Content-Type: text/plain ------_=_NextPart_005_01C09B6F.B5E9AFC0 Content-Type: text/html

  ------_=_NextPart_005_01C09B6F.B5E9AFC0-- ------_=_NextPart_004_01C09B6F.B5E9AFC0 Content-Type: application/octet-stream; name="ATT22972" Content-Disposition: attachment; filename="ATT22972" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010214135220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ngtrans-dstm-04.txt ------_=_NextPart_004_01C09B6F.B5E9AFC0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-ngtrans-dstm-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_004_01C09B6F.B5E9AFC0-- ------_=_NextPart_002_01C09B6F.B5E9AFC0-- ------_=_NextPart_000_01C09B6F.B5E9AFC0-- From owner-dhcp-v4@bucknell.edu Thu Feb 22 13:25:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21536 for ; Thu, 22 Feb 2001 13:25:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1MIJIL21741; Thu, 22 Feb 2001 13:19:18 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1MIJFL15317 for ; Thu, 22 Feb 2001 13:19:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-145.cisco.com [161.44.133.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10517 for ; Thu, 22 Feb 2001 13:18:57 -0500 (EST) Message-Id: <4.3.2.7.2.20010222130755.03cf9b18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 13:18:51 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for DHCP failover Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "DHCP Failover Protocol", . The WG discussed the previous revision in San Diego and agreed to go to WG last call before the Minneapolis meeting. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Wednesday, February 28. - Ralph Droms From owner-dhcp-v6@bucknell.edu Fri Feb 23 12:10:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09274; Fri, 23 Feb 2001 12:10:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1NH4jL21795; Fri, 23 Feb 2001 12:04:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1NH4gL04408; Fri, 23 Feb 2001 12:04:42 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-145.cisco.com [161.44.133.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22167; Fri, 23 Feb 2001 12:04:25 -0500 (EST) Message-Id: <4.3.2.7.2.20010223115717.037f8518@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 12:04:23 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in Minneapolis 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 The DHC WG has tentatively been scheduled for two meetings in Minneapolis. ***Note that the second session has been rescheduled from Tuesday to Wednesday!!!***. We will use the Monday afternoon meeting for DHCPv4 issues and the Wednesday morning meeting for DHCPv6; see below for DHC meetings and for concurrently scheduled WG meetings. Please submit any agenda items for either session to me so I can put together agendas for both meetings. So far, I have the following agenda items: DHCPv4: ------- Announcements from the chair DHCP MIB: prepare for WG last call DHCPv6: ------- Review draft rev -16 Discuss outstanding issues - Ralph MONDAY, March 19, 2001 1530-1730 Afternoon Sessions II APP impp Instant Messaging and Presence Protocol WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG RTG pim Protocol Independent Multicast WG SEC secsh Secure Shell WG TSV nfsv4 Network File System Version 4 WG WEDNESDAY, March 21, 2001 0900-1130 Morning Sessions APP ipp Internet Printing Protocol WG APP ldapbis LDAP (v3) Revision WG GEN ccamp Common Control and Measurement Plane WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG SEC idwg Intrusion Detection Exchange Format WG TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG From owner-dhcp-v4@bucknell.edu Fri Feb 23 12:13:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09444 for ; Fri, 23 Feb 2001 12:13:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1NH4jL03480; Fri, 23 Feb 2001 12:04:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1NH4gL04408; Fri, 23 Feb 2001 12:04:42 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-145.cisco.com [161.44.133.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22167; Fri, 23 Feb 2001 12:04:25 -0500 (EST) Message-Id: <4.3.2.7.2.20010223115717.037f8518@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 12:04:23 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meetings in Minneapolis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The DHC WG has tentatively been scheduled for two meetings in Minneapolis. ***Note that the second session has been rescheduled from Tuesday to Wednesday!!!***. We will use the Monday afternoon meeting for DHCPv4 issues and the Wednesday morning meeting for DHCPv6; see below for DHC meetings and for concurrently scheduled WG meetings. Please submit any agenda items for either session to me so I can put together agendas for both meetings. So far, I have the following agenda items: DHCPv4: ------- Announcements from the chair DHCP MIB: prepare for WG last call DHCPv6: ------- Review draft rev -16 Discuss outstanding issues - Ralph MONDAY, March 19, 2001 1530-1730 Afternoon Sessions II APP impp Instant Messaging and Presence Protocol WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG RTG pim Protocol Independent Multicast WG SEC secsh Secure Shell WG TSV nfsv4 Network File System Version 4 WG WEDNESDAY, March 21, 2001 0900-1130 Morning Sessions APP ipp Internet Printing Protocol WG APP ldapbis LDAP (v3) Revision WG GEN ccamp Common Control and Measurement Plane WG INT dhc Dynamic Host Configuration WG OPS policy Policy Framework WG SEC idwg Intrusion Detection Exchange Format WG TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG From owner-dhcp-v6@bucknell.edu Fri Feb 23 12:21:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09835; Fri, 23 Feb 2001 12:21:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1NHKlL27362; Fri, 23 Feb 2001 12:20:47 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1NHKVL03642; Fri, 23 Feb 2001 12:20:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-145.cisco.com [161.44.133.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23986; Fri, 23 Feb 2001 12:20:13 -0500 (EST) Message-Id: <4.3.2.7.2.20010223121816.0383e920@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 12:20:08 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: DHC WG meetings in Minneapolis In-Reply-To: <66F66129A77AD411B76200508B65AC691F64CA@eambunt705.ena-east .ericsson.se> 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 Oops - sorry for the confusion. The preliminary agenda for the WG meeting in Minneapolis should have referred to rev -17 of the DHCPv6 spec: DHCPv6: ------- Review draft rev -17 Discuss outstanding issues - Ralph From owner-dhcp-v4@bucknell.edu Fri Feb 23 12:22:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09867 for ; Fri, 23 Feb 2001 12:22:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1NHKlL07162; Fri, 23 Feb 2001 12:20:47 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1NHKVL03642; Fri, 23 Feb 2001 12:20:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-145.cisco.com [161.44.133.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23986; Fri, 23 Feb 2001 12:20:13 -0500 (EST) Message-Id: <4.3.2.7.2.20010223121816.0383e920@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 12:20:08 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: DHC WG meetings in Minneapolis In-Reply-To: <66F66129A77AD411B76200508B65AC691F64CA@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Oops - sorry for the confusion. The preliminary agenda for the WG meeting in Minneapolis should have referred to rev -17 of the DHCPv6 spec: DHCPv6: ------- Review draft rev -17 Discuss outstanding issues - Ralph From owner-dhcp-v4@bucknell.edu Fri Feb 23 18:50:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27090 for ; Fri, 23 Feb 2001 18:50:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1NNiVL20734; Fri, 23 Feb 2001 18:44:31 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1NNiIL09436 for ; Fri, 23 Feb 2001 18:44:18 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f1NNiGg15841 for ; Fri, 23 Feb 2001 15:44:16 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f1NNgKO13708 for ; Fri, 23 Feb 2001 16:42:20 -0700 (MST) Message-Id: <200102232342.f1NNgKO13708@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: draft-ietf-dhc-concat-null.txt Date: Fri, 23 Feb 2001 16:42:20 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is the draft we talked about in San Diego that is needed by both the domain search list draft and the classless static routes draft. Unfortunately, I missed the cutoff by a minute and thirty seconds, and I just got a message back from the draft editor saying that my submission will be ignored. However, I think it would be good to consider this draft at the working group meeting. So here it is - if you can give it a read prior to the meeting, that would be much appreciated. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. New draft February, 2001 Expires August, 2001 Encoding Long DHCP Options Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. Introduction The DHCP protocol [1] specifies objects called "options" that are encoded in the DHCP packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255. In some cases it may be useful to send DHCP options that are longer than 255 bytes, however. RFC2131 [1] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur. We specify here an ordering that can be used by DHCP protocol agents when sending and receiving options with more than 255 bytes. Clients and servers MAY use the ordering described here to encode existing options if such options exceed 255 bytes in length. The main purpose of this specification, however, is to provide a specification that new DHCP option drafts can reference. Terminology DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification. Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendesvous with DHCP servers, and so on. Option overload The DHCP packet format is based on the BOOTP packet format defined in [4]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the actual option buffer, the server name buffer, and the filename buffer. The DHCP options specification [2] defines the DHCP Overload option, which specifies which of these three buffers is actually being used in any given DHCP message to store DHCP options. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. Applicability This specification applies in any case where a DHCP protocol agent is encoding a packet containing options, and some of those options must be broken into parts. This can occur either because such an option is longer than 255 bytes, or because there is not sufficient space in any available buffer to store the entire option. DHCP protocol agents encoding an option in this case MAY follow the algorithm specfied here. This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. DHCP protocol agents that are decoding such options MAY follow the algorithm specified here. The rationale for making this optional is that existing implementations have not been subject to a requirement to encode or decode options in this way, and it is not our intention to potentially cause existing implementations to be in violation of this specification. The aggregate option buffer This behaviour only applies in cases where this specification is applicable, as previously defined in the Applicability section. DHCP options can be stored in the DHCP packet in three seperate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in [1]. This complicates the description of the option splitting mechanism because there are three seperate buffers into which split options may be stored. To further complicate matters, an option that doesn't fit into one buffer can't overlap the boundary into another buffer - the encoding agent must instead break the option into two parts and store one part in each buffer. To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in [1]. The aggregate option buffer is made up of the optional parameters field, the sname field, and the file field, in that order. Options MUST NOT be stored in the aggregate option buffer in such in such a way that they cross one either boundary between the three fields in the aggregate buffer. Encoding agent behaviour Encoding agents MAY split options as described in this specification. Encoding agents supporting options that require this MUST split options as described here, if it is necessary to do so in order to encode the entire contents of the option. Options MAY be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the output buffer in sequential order - the first split portion MUST be stored first in the output buffer, then the second portion, and so on. Each split portion of an option MUST be stored in the output buffer in the same way that a full option would be stored - each portion contains a single byte option type code, and then a single byte indicating the length of the portion of the option payload being stored in that portion, and then the payload itself. The length byte MUST NOT include itself or the option code. For any given option being split, the option code MUST be the same. Decoding agent behaviour When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MAY consider them to be a split option as described here. Decoding agents that support options that require the behaviour described in this draft MUST consider such options to be split. In the case that a decoding agent finds a split option, it must treat the contents of that option as a single option, and the contents must be ordered as described above under encoding agent behaviour. The decoding agent MUST ensure that when the option's value is used, any alignment issues that are particular to the machine architecture of the client are accounted for - there is no requirement that the encoding agent align the options in any particular way. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: mellon@nominum.com Expiration This document will expire on August 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Sun Feb 25 16:28:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13411 for ; Sun, 25 Feb 2001 16:28:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1PLMEL06133; Sun, 25 Feb 2001 16:22:14 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1PLM7L15434 for ; Sun, 25 Feb 2001 16:22:08 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1PLM6r16130 for ; Sun, 25 Feb 2001 15:22:06 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1PLM6R10514 for ; Sun, 25 Feb 2001 15:22:06 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Feb 25 15:23:28 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Feb 2001 15:23:28 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F64CC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-concat-null.txt Date: Sun, 25 Feb 2001 15:23:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09F71.31437840" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09F71.31437840 Content-Type: text/plain; charset="iso-8859-1" Ted: Looks very good. You might want to fix up the following paragraph: The aggregate option buffer is made up of the optional parameters field, the sname field, and the file field, in that order. Options MUST NOT be stored in the aggregate option buffer in such in such a way that they cross one either boundary between the ^^^^^^^ ^^^^(a)^^^ three fields in the aggregate buffer. Also, what exactly is the following supposed to mean? ... The decoding agent MUST ensure that when the option's value is used, any alignment issues that are particular to the machine architecture of the client are accounted for - there is no requirement that the encoding agent align the options in any particular way. How exactly is a relay or server supposed to know alignment issues/machine architecture for a client? Why does anything need to be aligned? We're dealing with byte strings (in network byte order) and the format of the options is specified in the various documents that define the options. If a dhcp agent does want to 'align' anything it can insert Pad Options (option 0) as desired BETWEEN options. Finally, it might be useful to give an example? Perhaps something as trivial as: As an example suppose a DHCP Server is sending a DHCPOFFER to a client and needs to split the Domain Name option (15) [RFC 2132] for "isc.org": Original option: +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 15 | 7 | 'i' | 's' | 'c' | '.' | 'o' | 'r' | 'g' | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ Could be split in 2, as follows: +-----+-----+-----+-----+-----+ | 15 | 3 | 'i' | 's' | 'c' | +-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+ | 15 | 4 | '.' | 'o' | 'r' | 'g' | +-----+-----+-----+-----+-----+-----+ Note: '' was used for clarity. - Bernie Volz Ericsson -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, February 23, 2001 6:42 PM To: DHCPv4 discussion list Subject: draft-ietf-dhc-concat-null.txt This is the draft we talked about in San Diego that is needed by both the domain search list draft and the classless static routes draft. Unfortunately, I missed the cutoff by a minute and thirty seconds, and I just got a message back from the draft editor saying that my submission will be ignored. However, I think it would be good to consider this draft at the working group meeting. So here it is - if you can give it a read prior to the meeting, that would be much appreciated. _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. New draft February, 2001 Expires August, 2001 Encoding Long DHCP Options Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. Introduction The DHCP protocol [1] specifies objects called "options" that are encoded in the DHCP packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255. In some cases it may be useful to send DHCP options that are longer than 255 bytes, however. RFC2131 [1] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur. We specify here an ordering that can be used by DHCP protocol agents when sending and receiving options with more than 255 bytes. Clients and servers MAY use the ordering described here to encode existing options if such options exceed 255 bytes in length. The main purpose of this specification, however, is to provide a specification that new DHCP option drafts can reference. Terminology DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification. Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendesvous with DHCP servers, and so on. Option overload The DHCP packet format is based on the BOOTP packet format defined in [4]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the actual option buffer, the server name buffer, and the filename buffer. The DHCP options specification [2] defines the DHCP Overload option, which specifies which of these three buffers is actually being used in any given DHCP message to store DHCP options. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. Applicability This specification applies in any case where a DHCP protocol agent is encoding a packet containing options, and some of those options must be broken into parts. This can occur either because such an option is longer than 255 bytes, or because there is not sufficient space in any available buffer to store the entire option. DHCP protocol agents encoding an option in this case MAY follow the algorithm specfied here. This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. DHCP protocol agents that are decoding such options MAY follow the algorithm specified here. The rationale for making this optional is that existing implementations have not been subject to a requirement to encode or decode options in this way, and it is not our intention to potentially cause existing implementations to be in violation of this specification. The aggregate option buffer This behaviour only applies in cases where this specification is applicable, as previously defined in the Applicability section. DHCP options can be stored in the DHCP packet in three seperate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in [1]. This complicates the description of the option splitting mechanism because there are three seperate buffers into which split options may be stored. To further complicate matters, an option that doesn't fit into one buffer can't overlap the boundary into another buffer - the encoding agent must instead break the option into two parts and store one part in each buffer. To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in [1]. The aggregate option buffer is made up of the optional parameters field, the sname field, and the file field, in that order. Options MUST NOT be stored in the aggregate option buffer in such in such a way that they cross one either boundary between the three fields in the aggregate buffer. Encoding agent behaviour Encoding agents MAY split options as described in this specification. Encoding agents supporting options that require this MUST split options as described here, if it is necessary to do so in order to encode the entire contents of the option. Options MAY be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the output buffer in sequential order - the first split portion MUST be stored first in the output buffer, then the second portion, and so on. Each split portion of an option MUST be stored in the output buffer in the same way that a full option would be stored - each portion contains a single byte option type code, and then a single byte indicating the length of the portion of the option payload being stored in that portion, and then the payload itself. The length byte MUST NOT include itself or the option code. For any given option being split, the option code MUST be the same. Decoding agent behaviour When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MAY consider them to be a split option as described here. Decoding agents that support options that require the behaviour described in this draft MUST consider such options to be split. In the case that a decoding agent finds a split option, it must treat the contents of that option as a single option, and the contents must be ordered as described above under encoding agent behaviour. The decoding agent MUST ensure that when the option's value is used, any alignment issues that are particular to the machine architecture of the client are accounted for - there is no requirement that the encoding agent align the options in any particular way. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: mellon@nominum.com Expiration This document will expire on August 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. ------_=_NextPart_001_01C09F71.31437840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-dhc-concat-null.txt

Ted:

Looks very good.

You might want to fix up the following = paragraph:

     The aggregate option buffer = is made up of the optional parameters
     field, the sname field, and = the file field, in that order.
     Options MUST NOT be stored = in the aggregate option buffer in such
     in such a way that they = cross one either boundary between the
     = ^^^^^^^           = ;            = ^^^^(a)^^^
     three fields in the = aggregate buffer.

Also, what exactly is the following supposed to = mean?

     ... The decoding agent MUST = ensure that when the
     option's value is used, any = alignment issues that are particular
     to the machine architecture = of the client are accounted for -
     there is no requirement = that the encoding agent align the options
     in any particular = way.

How exactly is a relay or server supposed to know = alignment issues/machine architecture for a client? Why does anything = need to be aligned? We're dealing with byte strings (in network byte = order) and the format of the options is specified in the various = documents that define the options.

If a dhcp agent does want to 'align' anything it can = insert Pad Options (option 0) as desired BETWEEN options.

Finally, it might be useful to give an example? = Perhaps something as trivial as:

As an example suppose a DHCP Server is sending a = DHCPOFFER to a client and needs to split the Domain Name option (15) = [RFC 2132] for "isc.org":

Original option:

   = +-----+-----+-----+-----+-----+-----+-----+-----+-----+
   | 15  |  7  | 'i' | 's' = | 'c' | '.' | 'o' | 'r' | 'g' |
   = +-----+-----+-----+-----+-----+-----+-----+-----+-----+

Could be split in 2, as follows:

   +-----+-----+-----+-----+-----+
   | 15  |  3  | 'i' | 's' = | 'c' |
   +-----+-----+-----+-----+-----+

   = +-----+-----+-----+-----+-----+-----+
   | 15  |  4  | '.' | 'o' = | 'r' | 'g' |
   = +-----+-----+-----+-----+-----+-----+

Note: '<character>' was used for = clarity.

- Bernie Volz
  Ericsson





-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, February 23, 2001 6:42 PM
To: DHCPv4 discussion list
Subject: draft-ietf-dhc-concat-null.txt



This is the draft we talked about in San Diego that = is needed by both
the domain search list draft and the classless = static routes draft.
Unfortunately, I missed the cutoff by a minute and = thirty seconds, and
I just got a message back from the draft editor = saying that my
submission will be ignored.  However, I think = it would be good to
consider this draft at the working group = meeting.  So here it is - if
you can give it a read prior to the meeting, that = would be much
appreciated.

        =         =                _MelloN_

Network Working = Group           &= nbsp;           &= nbsp;           &= nbsp;      Ted Lemon
Internet Draft  =         =         =         =         =            Nominum, = Inc.

New draft       =         =         =         =         =           February, 2001
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;     Expires August, 2001


        =               Encoding Long DHCP = Options
        =            = <draft-ietf-dhc-concat-null.txt>

Status of this Memo

   This document is an Internet-Draft and = is in full conformance with
   all provisions of Section 10 of = RFC2026.

   This document is an = Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering = Task Force (IETF), its areas,
   and its working groups.  Note that = other groups may also distribute
   working documents as = Internet-Drafts.

   Internet-Drafts are draft documents = valid for a maximum of six months
   and may be updated, replaced, or = obsoleted by other documents at any
   time.  It is inappropriate to use = Internet-Drafts as reference
   material or to cite them other than as = "work in progress".

     The list of current = Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft = Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

     This draft specifies how = DHCP options in a DHCP packet can be
     aggregated so that DHCP = protocol agents can send options that are
     more than 255 bytes in = length.

Introduction

     The DHCP protocol [1] = specifies objects called "options" that are
     encoded in the DHCP packet = to pass information between DHCP
     protocol agents.  = These options are encoded as a one-byte type
     code, a one-byte length, = and a buffer consisting of the number of
     bytes specified in the = length, from zero to 255.

     In some cases it may be = useful to send DHCP options that are
     longer than 255 bytes, = however.  RFC2131 [1] specifies that when
     more than one option with a = given type code appears in the DHCP
     packet, all such options = should be concatenated together.   It
     does not, however, specify = the order in which this concatenation
     should occur.

     We specify here an ordering = that can be used by DHCP protocol
     agents when sending and = receiving options with more than 255
     bytes.   Clients = and servers MAY use the ordering described here
     to encode existing options = if such options exceed 255 bytes in
     length.   The = main purpose of this specification, however, is to
     provide a specification = that new DHCP option drafts can
=0C



     reference.

Terminology

     DHCP protocol agents
        This = refers to any device on the network that sends or
        receives = DHCP packets - any DHCP client, server or relay
        agent.   The nature of these devices is not = important to this
        specification.
     Options
        DHCP = options are collections of data with type codes that
        indicate = how the options should be used.   Options can specify
        information that is required for the DHCP protocol,
        IP stack = configuration parameters for the client, information
        allowing = the client to rendesvous with DHCP servers, and so
        on.
     Option overload
        The DHCP = packet format is based on the BOOTP packet format
        defined = in [4].   When used by DHCP protocol agents, BOOTP
        packets = have three fields that can contain options.   These
        are the = actual option buffer, the server name buffer, and the
        filename = buffer.   The DHCP options specification [2] defines
        the DHCP = Overload option, which specifies which of these three
        buffers = is actually being used in any given DHCP message to
        store = DHCP options.

Requirements language

     In this document, the key = words "MAY", "MUST, "MUST NOT",
     "optional", = "recommended", "SHOULD", and "SHOULD = NOT", are to be
     interpreted as described in = [3].

Applicability

     This specification applies = in any case where a DHCP protocol
     agent is encoding a packet = containing options, and some of those
     options must be broken into = parts.   This can occur either
     because such an option is = longer than 255 bytes, or because there
     is not sufficient space in = any available buffer to store the
     entire option.   = DHCP protocol agents encoding an option in this
     case MAY follow the = algorithm specfied here.

     This specification also = applies in any case where a DHCP protocol
     agent has received a DHCP = packet that contains more than one
     instance of an option of a = given type.   DHCP protocol agents
     that are decoding such = options MAY follow the algorithm specified
     here.

     The rationale for making = this optional is that existing
     implementations have not = been subject to a requirement to encode
     or decode options in this = way, and it is not our intention to
     potentially cause existing = implementations to be in violation of
     this specification.

The aggregate option buffer

     This behaviour only applies = in cases where this specification is
     applicable, as previously = defined in the Applicability section.
=0C



     DHCP options can be stored = in the DHCP packet in three seperate
     portions of the = packet.   These are the optional parameters
     field, the sname field, and = the file field, as described in [1].
     This complicates the = description of the option splitting
     mechanism because there are = three seperate buffers into which
     split options may be = stored.

     To further complicate = matters, an option that doesn't fit into
     one buffer can't overlap = the boundary into another buffer - the
     encoding agent must instead = break the option into two parts and
     store one part in each = buffer.

     To simplify this discussion, = we will talk about an aggregate
     option buffer, which will = be the aggregate of the three buffers.
     This is a logical = aggregation - the buffers MUST appear in the
     locations in the DHCP = packet described in [1].

     The aggregate option buffer = is made up of the optional parameters
     field, the sname field, and = the file field, in that order.
     Options MUST NOT be stored = in the aggregate option buffer in such
     in such a way that they = cross one either boundary between the
     three fields in the = aggregate buffer.

Encoding agent behaviour

     Encoding agents MAY split = options as described in this
     specification.   = Encoding agents supporting options that require
     this MUST split options as = described here, if it is necessary to
     do so in order to encode = the entire contents of the option.

     Options MAY be split on any = octet boundary.  No split portion of
     an option that has been = split can contain more than 255 octets.
     The split portions of the = option MUST be stored in the output
     buffer in sequential order = - the first split portion MUST be
     stored first in the output = buffer, then the second portion, and
     so on.

     Each split portion of an = option MUST be stored in the output
     buffer in the same way that = a full option would be stored - each
     portion contains a single = byte option type code, and then a
     single byte indicating the = length of the portion of the option
     payload being stored in = that portion, and then the payload
     itself.   The = length byte MUST NOT include itself or the option
     code.   For any = given option being split, the option code MUST be
     the same.

Decoding agent behaviour

     When a decoding agent is = scanning an incoming DHCP packet's
     option buffer and finds two = or more options with the same option
     code, it MAY consider them = to be a split option as described
     here.  Decoding agents = that support options that require the
     behaviour described in this = draft MUST consider such options to
     be split.

     In the case that a decoding = agent finds a split option, it must
     treat the contents of that = option as a single option, and the
=0C




     contents must be ordered as = described above under encoding agent
     behaviour.   The = decoding agent MUST ensure that when the
     option's value is used, any = alignment issues that are particular
     to the machine architecture = of the client are accounted for -
     there is no requirement = that the encoding agent align the options
     in any particular = way.
    
Security Considerations

     DHCP currently provides no = authentication or security mechanisms.
     Potential exposures to = attack are discussed in section 7 of the DHCP
     protocol specification [1]. = The Classless Static Routes option can
     be used to misdirect = network traffic by providing incorrect IP
     addresses for = routers.

References

 [1] Droms, R., "Dynamic Host Configuration = Protocol", RFC 2131,
     Bucknell University, March = 1997.
 [2] Alexander, S. and Droms, R., "DHCP = Options and BOOTP Vendor
     Extensions", RFC 2132, = Silicon Graphics, Inc., Bucknell
     University, March = 1997.
 [3] Bradner, S., "Key words for use in = RFCs to indicate requirement
     levels", RFC 2119, = Harvard University, March 1997.
 [4] Mogul, J., Postel, J., "Internet = Standard Subnetting
     Procedure", RFC950, = Stanford University, USC/Information
     Sciences Institute, August = 1985.

Author Information

Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
email: mellon@nominum.com

Expiration

   This document will expire on August 31, = 2001.

Full Copyright Statement

   Copyright (C) The Internet Society = (2001).  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.
=0C




   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.

------_=_NextPart_001_01C09F71.31437840-- From owner-dhcp-v4@bucknell.edu Sun Feb 25 16:44:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13481 for ; Sun, 25 Feb 2001 16:44:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1PLhKL11628; Sun, 25 Feb 2001 16:43:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1PLftL26328 for ; Sun, 25 Feb 2001 16:41:55 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1PLfsr17689 for ; Sun, 25 Feb 2001 15:41:54 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1PLfsR11218 for ; Sun, 25 Feb 2001 15:41:54 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Feb 25 15:43:18 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Feb 2001 15:43:18 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F64CF@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: WG last call for DHCP failover Date: Sun, 25 Feb 2001 15:43:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09F73.F68CC550" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09F73.F68CC550 Content-Type: text/plain; charset="iso-8859-1" Technically (at least by the text of the draft) it has expired. However, I think the last edit didn't update the published/expiration date in the draft (IETF Web site lists the 08 draft submission date as 11/28/00). I do have a bunch of comments regarding this draft, though most are editorial clarifications and not really significant content changes. I will send these directly to Kim (cc Ralph) unless someone feels that they'd like to see them. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 22, 2001 1:19 PM To: DHCPv4 discussion list Subject: WG last call for DHCP failover This message announces a DHC WG last call for "DHCP Failover Protocol", . The WG discussed the previous revision in San Diego and agreed to go to WG last call before the Minneapolis meeting. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Wednesday, February 28. - Ralph Droms ------_=_NextPart_001_01C09F73.F68CC550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG last call for DHCP failover

Technically (at least by the text of the draft) it = has expired. However, I think the last edit didn't update the = published/expiration date in the draft (IETF Web site lists the 08 = draft submission date as 11/28/00).

I do have a bunch of comments regarding this draft, = though most are editorial clarifications and not really significant = content changes. I will send these directly to Kim (cc Ralph) unless = someone feels that they'd like to see them.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, February 22, 2001 1:19 PM
To: DHCPv4 discussion list
Subject: WG last call for DHCP failover


This message announces a DHC WG last call for = "DHCP Failover Protocol",
<draft-ietf-dhc-failover-08.txt>.  The WG = discussed the previous revision
in San Diego and agreed to go to WG last call before = the Minneapolis meeting.

Please forward any comments you may have on this = draft to
dhcp-v4@bucknell.edu by Wednesday, February = 28.

- Ralph Droms

------_=_NextPart_001_01C09F73.F68CC550-- From owner-dhcp-v4@bucknell.edu Mon Feb 26 15:05:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24898 for ; Mon, 26 Feb 2001 15:05:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1QJv5L26278; Mon, 26 Feb 2001 14:57:05 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1QJuFL07093 for ; Mon, 26 Feb 2001 14:56:15 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f1QJu0g20911; Mon, 26 Feb 2001 11:56:04 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f1QJtH300469; Mon, 26 Feb 2001 12:55:17 -0700 (MST) Message-Id: <200102261955.f1QJtH300469@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-concat-null.txt In-Reply-To: Message from "Bernie Volz (EUD)" of "Sun, 25 Feb 2001 15:23:27 CST." <66F66129A77AD411B76200508B65AC691F64CC@eambunt705.ena-east.ericsson.se> Date: Mon, 26 Feb 2001 12:55:17 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for the comments, Bernie! > in such a way that they cross one either boundary between the > ^^^^^^^ ^^^^(a)^^^ The "one" there is an editing error - the sentence seems to make sense without it... :'} > ... The decoding agent MUST ensure that when the > option's value is used, any alignment issues that are particular > to the machine architecture of the client are accounted for - > there is no requirement that the encoding agent align the options > in any particular way. I used "client" when I should have used "decoding agent." The decoding agnt knows its own alignment issues - that's all I was trying to say. It would be completely wrong to require the encoding agent to be aware of the decoding agent's alignment issues. > Finally, it might be useful to give an example? Perhaps something as trivial as: > > As an example suppose a DHCP Server is sending a DHCPOFFER to a client and needs to split the Domain Name option (15) [RFC 2132] for "isc.org": Sounds good. Thanks! _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Feb 26 15:22:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25753 for ; Mon, 26 Feb 2001 15:22:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1QKLUL19016; Mon, 26 Feb 2001 15:21:30 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1QKLHL08640 for ; Mon, 26 Feb 2001 15:21:18 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13991; Mon, 26 Feb 2001 12:21:15 -0800 (PST) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AIB02455; Mon, 26 Feb 2001 12:20:54 -0800 (PST) Received: (from raj@localhost) by kitab.cisco.com (8.11.0/8.9.2) id f1QKKr600500; Mon, 26 Feb 2001 12:20:53 -0800 (PST) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.47780.948176.149019@kitab.cisco.com> Date: Mon, 26 Feb 2001 12:20:52 -0800 To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-concat-null.txt In-Reply-To: <200102232342.f1NNgKO13708@grosse.bisbee.fugue.com> References: <200102232342.f1NNgKO13708@grosse.bisbee.fugue.com> X-Mailer: VM 6.90 under 20.4 "Emerald" XEmacs Lucid Reply-To: raj@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I just want to clarify something. Maybe I just missed it in the draft. When you say: The split portions of the option MUST be stored in the output buffer in sequential order - the first split portion MUST be stored first in the output buffer, then the second portion, and so on. This means that if we have, for example, a option being split into three parts and stored in all three areas (the optional parameters field, the sname field, and the file field), the first part of the three must be the one stored in the sname field (since it appears first in the packet), the second MUST be in the file field (since it appears second in the packet), and the last part would be in the options field. I.e., when gathering up option information, it would be best to scan the packet in the order of "sname field", "file field", then "options field", and append option information as it is encountered. Is this correct? I'm asking because I think probably most implementation would currently scan the "options field" first and then optionally scan the other two, which would append option information in an incorrect order. /raj From owner-dhcp-v4@bucknell.edu Mon Feb 26 16:13:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27792 for ; Mon, 26 Feb 2001 16:13:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1QL7CL03096; Mon, 26 Feb 2001 16:07:13 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1QL74L21611 for ; Mon, 26 Feb 2001 16:07:05 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f1QL6qg24565; Mon, 26 Feb 2001 13:06:52 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f1QL5C300709; Mon, 26 Feb 2001 14:05:12 -0700 (MST) Message-Id: <200102262105.f1QL5C300709@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-concat-null.txt In-Reply-To: Message from Richard Johnson of "Mon, 26 Feb 2001 12:20:52 PST." <15002.47780.948176.149019@kitab.cisco.com> Date: Mon, 26 Feb 2001 14:05:12 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The split portions of the option MUST be stored in the output > buffer in sequential order - the first split portion MUST be > stored first in the output buffer, then the second portion, and > so on. That should be the aggregate output buffer. The ordering is option buffer first, then sname, then file, if I remember correctly. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Feb 26 16:20:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28059 for ; Mon, 26 Feb 2001 16:20:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1QLJdL17813; Mon, 26 Feb 2001 16:19:39 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1QLJYL02901 for ; Mon, 26 Feb 2001 16:19:35 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA10614; Mon, 26 Feb 2001 13:19:33 -0800 (PST) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AIB03621; Mon, 26 Feb 2001 13:19:07 -0800 (PST) Received: (from raj@localhost) by kitab.cisco.com (8.11.0/8.9.2) id f1QLJ6x00541; Mon, 26 Feb 2001 13:19:06 -0800 (PST) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.51273.313032.621397@kitab.cisco.com> Date: Mon, 26 Feb 2001 13:19:05 -0800 To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-concat-null.txt In-Reply-To: <200102262105.f1QL5C300709@grosse.bisbee.fugue.com> References: <15002.47780.948176.149019@kitab.cisco.com> <200102262105.f1QL5C300709@grosse.bisbee.fugue.com> X-Mailer: VM 6.90 under 20.4 "Emerald" XEmacs Lucid Reply-To: raj@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ted Lemon writes: > That should be the aggregate output buffer. The ordering is option > buffer first, then sname, then file, if I remember correctly. Oops, actually, it's "file" then "sname" as specified in rfc2131: The options in the 'options' field MUST be interpreted first, so that any 'option overload' options may be interpreted. The 'file' field MUST be interpreted next (if the 'option overload' option indicates that the 'file' field contains DHCP options), followed by the 'sname' field. I had momentarily forgotten about that text. Thanks. Maybe this should be referenced. /raj From owner-dhcp-v4@bucknell.edu Mon Feb 26 16:31:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28475 for ; Mon, 26 Feb 2001 16:31:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1QLSOL11224; Mon, 26 Feb 2001 16:28:26 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1QLRoL26600 for ; Mon, 26 Feb 2001 16:27:52 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f1QLRgg24635; Mon, 26 Feb 2001 13:27:42 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f1QLPk300761; Mon, 26 Feb 2001 14:25:46 -0700 (MST) Message-Id: <200102262125.f1QLPk300761@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-concat-null.txt In-Reply-To: Message from Richard Johnson of "Mon, 26 Feb 2001 12:20:52 PST." <15002.47780.948176.149019@kitab.cisco.com> Date: Mon, 26 Feb 2001 14:25:46 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've reworded things a bit to fix your concern. My intention was exactly the opposite of how you read the documentation, so I obviously need to be clearer. :'} _MelloN_ Network Working Group Ted Lemon Internet Draft Nominum, Inc. New draft February, 2001 Expires August, 2001 Encoding Long DHCP Options Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. Introduction The DHCP protocol [1] specifies objects called "options" that are encoded in the DHCP packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255. In some cases it may be useful to send DHCP options that are longer than 255 bytes, however. RFC2131 [1] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur. We specify here an ordering that can be used by DHCP protocol agents when sending and receiving options with more than 255 bytes. DHCP protocol agents MAY use the ordering described here to encode existing options if such options exceed 255 bytes in length. The main purpose of this specification, however, is to provide a specification that new DHCP option drafts can reference. Terminology DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification. Encoding agent The DHCP protocol agent that is composing a DHCP packet to send. Decoding agent The DHCP protocol agent that is processing a DHCP packet it has received. Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendesvous with DHCP servers, and so on. Option overload The DHCP packet format is based on the BOOTP packet format defined in [4]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the actual option buffer, the server name buffer, and the filename buffer. The DHCP options specification [2] defines the DHCP Overload option, which specifies which of these three buffers is actually being used in any given DHCP message to store DHCP options. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. Applicability This specification applies in any case where a DHCP protocol agent is encoding a packet containing options, and some of those options must be broken into parts. This can occur either because such an option is longer than 255 bytes, or because there is not sufficient space in the current output buffer to store the option, but there is space for part of the option, and there is space in another output buffer for the rest. DHCP protocol agents encoding an option in this case MAY use the algorithm specified here. This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. DHCP protocol agents that are decoding such options MAY follow the algorithm specified here. The rationale for making this optional is that existing implementations have not been subject to a requirement to encode or decode options in this way, and it is not our intention to potentially cause existing implementations to be in violation of this specification. The aggregate option buffer This behaviour only applies in cases where this specification is applicable, as previously defined in the Applicability section. DHCP options can be stored in the DHCP packet in three seperate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in [1]. This complicates the description of the option splitting mechanism because there are three seperate buffers into which split options may be stored. To further complicate matters, an option that doesn't fit into one buffer can't overlap the boundary into another buffer - the encoding agent must instead break the option into two parts and store one part in each buffer. To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in [1]. The aggregate option buffer is made up of the optional parameters field, the sname field, and the file field, in that order. WARNING: This is not the physical ordering of these fields in the DHCP packet. Options MUST NOT be stored in the aggregate option buffer in such in such a way that they cross either boundary between the three fields in the aggregate buffer. Encoding agent behaviour Encoding agents MAY split options as described in this specification. Encoding agents supporting options that require this MUST split options as described here, if it is necessary to do so in order to encode the entire contents of the option. Options MAY be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the output buffer in sequential order - the first split portion MUST be stored first in the aggregate option buffer, then the second portion, and so on. Each split portion of an option MUST be stored in the aggregate option buffer in the same way that a full option would be stored - each portion contains a single byte option type code, and then a single byte indicating the length of the portion of the option payload being stored in that portion, and then the payload itself. The length byte MUST NOT include itself or the option code. For any given option being split, the option code MUST be the same. Note that because the aggregate option buffer does not represent the physical ordering of the DHCP packet, if an option were split into three parts and each part went into one of the possible option fields, the first part would go into the optional parameters field, the second part would go into the sname field, and the third part would go into the file field. Decoding agent behaviour When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MAY consider them to be a split option as described here. Decoding agents that support options that require the behaviour described in this draft MUST consider such options to be split. In the case that a decoding agent finds a split option, it must treat the contents of that option as a single option, and the contents must be ordered as described above under encoding agent behaviour. The decoding agent MUST ensure that when the option's value is used, any alignment issues that are particular to the machine architecture on which the decoding agent is running are accounted for - there is no requirement that the encoding agent align the options in any particular way. Example Consider an option, option 224, with a value of "isc.org.". Normally, this would be encoded as a single option, as follows: +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 224 | 8 | 'i' | 's' | 'c' | '.' | 'o' | 'r' | 'g' | '.' | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ If an encoding agent needed to split the option in order to fit it into the option buffer, it could encode it as two seperate options, as follows, and store it in the aggregate option buffer in the following sequence: +-----+-----+-----+-----+-----+-----+-----+ | 224 | 5 | 'i' | 's' | 'c' | '.' | 'o' | +-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+ | 224 | 3 | 'r' | 'g' | '.' | +-----+-----+-----+-----+-----+ Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. The Classless Static Routes option can be used to misdirect network traffic by providing incorrect IP addresses for routers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell University, March 1997. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, Harvard University, March 1997. [4] Mogul, J., Postel, J., "Internet Standard Subnetting Procedure", RFC950, Stanford University, USC/Information Sciences Institute, August 1985. Author Information Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 email: mellon@nominum.com Expiration This document will expire on August 31, 2001. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Tue Feb 27 04:50:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02316 for ; Tue, 27 Feb 2001 04:50:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1R9hpL08452; Tue, 27 Feb 2001 04:43:51 -0500 (EST) Received: from coral.bucknell.edu (coral.bucknell.edu [134.82.7.4]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1R9hgL24565 for ; Tue, 27 Feb 2001 04:43:42 -0500 (EST) Received: from smtp.alpha-soft.com ([12.8.241.171]) by coral.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA19281 for ; Tue, 27 Feb 2001 04:43:41 -0500 (EST) Received: from offset [130.244.215.215] by smtp.alpha-soft.com (SMTPD32-6.00) id A5F190CC005E; Tue, 27 Feb 2001 04:40:01 -0500 Reply-To: From: "Bud Millwood" To: DHCPv4 discussion list Subject: Implementing support for Option 82 Date: Tue, 27 Feb 2001 10:51:16 +0100 Message-ID: <000001c0a0a2$d3f8add0$3201a8c0@offset.weird.se> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Not sure if my previous question was unclear. I think some of you have implemented support for this option in your servers, so maybe I can get some guidance... It says: 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) But it also says: Servers MAY use the Circuit ID for IP and other parameter assignment policies. After re-reading RFC 3046 it seems that in order to say I support it I should be able to, at a minimum, limit leases by Remote ID or by Circuit ID. Does this seem like a sound approach? Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com From owner-dhcp-v4@bucknell.edu Tue Feb 27 15:00:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26873 for ; Tue, 27 Feb 2001 15:00:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1RJrpL26787; Tue, 27 Feb 2001 14:53:51 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1RJrKL11338 for ; Tue, 27 Feb 2001 14:53:21 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-140.cisco.com [161.44.133.140]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20086; Tue, 27 Feb 2001 14:52:57 -0500 (EST) Message-Id: <4.2.0.58.20010227144928.0213e090@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Feb 2001 14:53:08 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: RE: WG last call for DHCP failover Cc: DHCPv4 discussion list , kkinnear@cisco.com In-Reply-To: <66F66129A77AD411B76200508B65AC691F64CF@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 03:43 PM 2/25/01 -0600, Bernie Volz (EUD) wrote: >Technically (at least by the text of the draft) it has expired. However, I think the last edit didn't update the published/expiration date in the draft (IETF Web site lists the 08 draft submission date as 11/28/00). That's precisely correct. I *did* submit a new one in November, and while I managed to get the -07 turned into the -08, I clearly forgot to update the submitted and expired dates. Thanks for catching that problem. I also received your comments and will review them ASAP. Thanks (as usual) for your review. Cheers -- Kim >I do have a bunch of comments regarding this draft, though most are editorial clarifications and not really significant content changes. I will send these directly to Kim (cc Ralph) unless someone feels that they'd like to see them. > >- Bernie Volz > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, February 22, 2001 1:19 PM >To: DHCPv4 discussion list >Subject: WG last call for DHCP failover > >This message announces a DHC WG last call for "DHCP Failover Protocol", >. The WG discussed the previous revision >in San Diego and agreed to go to WG last call before the Minneapolis meeting. > >Please forward any comments you may have on this draft to >dhcp-v4@bucknell.edu by Wednesday, February 28. > >- Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Feb 27 17:52:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03940 for ; Tue, 27 Feb 2001 17:52:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1RMhqL29446; Tue, 27 Feb 2001 17:43:53 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1RMhnL17716 for ; Tue, 27 Feb 2001 17:43:49 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 27 Feb 2001 17:40:26 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 17:40:27 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E806F2AE95@zwdld001.ca.nortel.com> From: "Biswaroop Mukherjee" To: DHCPv4 discussion list Subject: RE: Why authenticate with DHCP? Date: Tue, 27 Feb 2001 17:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A10E.4635F810" X-Orig: Reply-To: biswaroo@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A10E.4635F810 Content-Type: text/plain Thanks for 802.11 references, Bernard. Authenticating and interfacing to AAA in 802.11 is a possible solution for 802.11 networks. But is it necessarily the right place to do it for all networks? What about the non-802.11 networks, like 3G networks. Are we assuming that all link layers would interface to AAA? Why not provide means of doing this at a higher layer, for instance DHCP? Any comments ? Cheers, -- Roop ------_=_NextPart_001_01C0A10E.4635F810 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Why authenticate with DHCP?

Thanks for 802.11 references, = Bernard.
Authenticating and interfacing to = AAA in 802.11 is a possible solution for 802.11 networks. But is it = necessarily the right place to do it for all networks?  What about = the non-802.11 networks, like 3G networks. Are we assuming that all = link layers would interface to AAA? Why not provide means of doing this = at a higher layer, for instance DHCP?

Any comments ?

        Cheers,
        -- Roop


------_=_NextPart_001_01C0A10E.4635F810-- From owner-dhcp-v6@bucknell.edu Tue Feb 27 18:17:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04582; Tue, 27 Feb 2001 18:17:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1RNEcL26913; Tue, 27 Feb 2001 18:14:42 -0500 (EST) Received: from rdroms-w2k.bucknell.edu (dhcp-128-107-133-53.cisco.com [128.107.133.53]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1RNESL09374 for ; Tue, 27 Feb 2001 18:14:28 -0500 (EST) Message-Id: <4.3.2.7.2.20010227181222.03515838@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 18:14:08 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: A proposal for DHCPv6 reconfiguration 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 Jim and I are finishing up the -17 rev of the DHCPv6 spec. I never saw any response to the following message. Unless I hear something different, this is what will go in the spec. - Ralph Assuming I got the list of multicast reconfigure issues from San Diego right, here is a list of goals for server-initiated configuration: * When the server has a complete list of the clients to be reconfigured, the server will know reliably that each client has either been reconfigured exactly once or has not responded to the server's reconfiguration request * When the server does not have a complete list of clients, the server will have some assurance that each client has received at least one Reconfigure-init message * Wherever possible, redundant or gratuitous reconfiguration of clients will be avoided (even though reconfiguring more than once should not affect correct client operation) * Clients and servers must be able to authenticate Reconfigure-init messages, to avoid denial-of-service attacks Here's my proposal for server-initiated configuration, intended to meet the listed goals (except for multicast authentication, which I don't have a solution for): Reliable unicast transmission can be managed through the use of the transaction-id. The server includes a unique transaction ID in each unicast Reconfigure-init message. The client responds to the first Reconfigure-init message it receives, copying the transaction ID into the Reply message the client sends to the server, and ignores all subsequent Reconfigure-init messages with the same transaction ID. This behavior causes the client to ignore duplicate copies of a single Reconfigure-init message. If the server does not receive a Reply to the Reconfigure-init with a matching transaction ID, the server can try again by transmitting a new Reconfigure-init with a new transaction ID. The new transaction ID will cause the client to start the reconfiguration process again, in case the client did not receive earlier Reconfigure-init messages or the server did not receive the client's Reply. The delay before a server retries with a new Reconfigure-init, the number of times the server should retry before giving up and the server's action when it can't reach a client are TBD. As an aside, the behavior of a client that receives a Reconfigure-init while expecting an Advertise or Reply is not currently defined and is TBD. For reconfiguration using multicast, the server multicasts an initial message Reconfigure-init several times with the same transaction ID. The number of retransmissions and the delay between retransmissions is TBD. The client behavior is the same as in the unicast Reocnfigure-inti message: each client in the multicast group to which the Reconfigure-init message was transmitted responds to first message it receives (not necessarily the first message transmitted by the server) and ignores all other Reconfigure-init messages with the same transaction ID. The server maintains a list of those clients that have responded to the multicast Reconfigure-init message. After the multicast Reconfigure-init messages have been transmitted, the server reverts to unicast with new transaction ID for clients that have not responded respond. To reduce the number of simultaneous Replies recieved by a server, the server can include a delay parameter in the Reconfigure-init message. Clients then choose random time between 0 and the delay parameter to respond with a Reply message. From owner-dhcp-v6@bucknell.edu Tue Feb 27 18:28:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04841; Tue, 27 Feb 2001 18:28:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1RNOkL23036; Tue, 27 Feb 2001 18:24:46 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1RNOgL14127 for ; Tue, 27 Feb 2001 18:24:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-128-107-133-53.cisco.com [128.107.133.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA16458 for ; Tue, 27 Feb 2001 18:24:25 -0500 (EST) Message-Id: <4.3.2.7.2.20010227181931.00b96f58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 18:24:21 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Teleconference on -17 rev of spec 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 We expect to submit the -17 rev of the draft for publication Wednesday, 2/28. I want to schedule a design team teleconference to discuss the -17 rev prior to our WG meetings in Minneapolis. I suggest the week of 3/12 - as a first proposal, how about Tuesday, 3/13, 12:30PM-3:30PM? If you want to participate in this design team teleconference, please contact me by 5PM EST, 3/2. If you want to participate but you are not available 3/13, 12:30PM, please let me know ASAP so I can propose another choice. - Ralph From owner-dhcp-v6@bucknell.edu Tue Feb 27 20:29:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08517; Tue, 27 Feb 2001 20:29:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1S1PSL10020; Tue, 27 Feb 2001 20:25:28 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1S1PCL31166 for ; Tue, 27 Feb 2001 20:25:13 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 17:22:23 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Feb 2001 17:21:29 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 17:21:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 Content-Class: urn:content-classes:message Subject: RE: A proposal for DHCPv6 reconfiguration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 Feb 2001 17:21:29 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A688C5892@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: A proposal for DHCPv6 reconfiguration Thread-Index: AcChFHu97+f4+le5QKWrXsayPTXP7AAD36+w From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 28 Feb 2001 01:21:29.0664 (UTC) FILETIME=[C70AC400:01C0A124] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f1S1PEL28188 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Ralph, thanks for driving this draft. I have a couple of questions regarding the paragraphs below: First: When the server has a complete list of the clients to be reconfigured, the server will know reliably that each client has either been reconfigured exactly once or has not responded to the server's reconfiguration request. What is meant by "complete list of clients to be reconfigured?". Is this something that is implementation specific? For example, the system administrator might want to specify that clients in subnet should be reconfigured. Or is this all the clients that are present in the DHCP Server database? Second: Clients and servers must be able to authenticate Reconfigure-init messages, to avoid denial-of-service attacks How do the clients and servers authenticate reconfigure-init messages? Is this based on XID? If this is not based on XID, we need a scheme where there is no user interaction at all. thx -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Tuesday, February 27, 2001 3:14 PM To: DHCPv6 discussion list Subject: A proposal for DHCPv6 reconfiguration Jim and I are finishing up the -17 rev of the DHCPv6 spec. I never saw any response to the following message. Unless I hear something different, this is what will go in the spec. - Ralph Assuming I got the list of multicast reconfigure issues from San Diego right, here is a list of goals for server-initiated configuration: * When the server has a complete list of the clients to be reconfigured, the server will know reliably that each client has either been reconfigured exactly once or has not responded to the server's reconfiguration request * When the server does not have a complete list of clients, the server will have some assurance that each client has received at least one Reconfigure-init message * Wherever possible, redundant or gratuitous reconfiguration of clients will be avoided (even though reconfiguring more than once should not affect correct client operation) * Clients and servers must be able to authenticate Reconfigure-init messages, to avoid denial-of-service attacks Here's my proposal for server-initiated configuration, intended to meet the listed goals (except for multicast authentication, which I don't have a solution for): Reliable unicast transmission can be managed through the use of the transaction-id. The server includes a unique transaction ID in each unicast Reconfigure-init message. The client responds to the first Reconfigure-init message it receives, copying the transaction ID into the Reply message the client sends to the server, and ignores all subsequent Reconfigure-init messages with the same transaction ID. This behavior causes the client to ignore duplicate copies of a single Reconfigure-init message. If the server does not receive a Reply to the Reconfigure-init with a matching transaction ID, the server can try again by transmitting a new Reconfigure-init with a new transaction ID. The new transaction ID will cause the client to start the reconfiguration process again, in case the client did not receive earlier Reconfigure-init messages or the server did not receive the client's Reply. The delay before a server retries with a new Reconfigure-init, the number of times the server should retry before giving up and the server's action when it can't reach a client are TBD. As an aside, the behavior of a client that receives a Reconfigure-init while expecting an Advertise or Reply is not currently defined and is TBD. For reconfiguration using multicast, the server multicasts an initial message Reconfigure-init several times with the same transaction ID. The number of retransmissions and the delay between retransmissions is TBD. The client behavior is the same as in the unicast Reocnfigure-inti message: each client in the multicast group to which the Reconfigure-init message was transmitted responds to first message it receives (not necessarily the first message transmitted by the server) and ignores all other Reconfigure-init messages with the same transaction ID. The server maintains a list of those clients that have responded to the multicast Reconfigure-init message. After the multicast Reconfigure-init messages have been transmitted, the server reverts to unicast with new transaction ID for clients that have not responded respond. To reduce the number of simultaneous Replies recieved by a server, the server can include a delay parameter in the Reconfigure-init message. Clients then choose random time between 0 and the delay parameter to respond with a Reply message. From owner-dhcp-v6@bucknell.edu Tue Feb 27 20:40:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08745; Tue, 27 Feb 2001 20:40:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1S1ZpL10122; Tue, 27 Feb 2001 20:35:51 -0500 (EST) Received: from rdroms-w2k.bucknell.edu (dhcp-128-107-133-53.cisco.com [128.107.133.53]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1S1ZcL19000 for ; Tue, 27 Feb 2001 20:35:38 -0500 (EST) Message-Id: <4.3.2.7.2.20010227203420.00b56690@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 20:35:17 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Teleconference on -17 rev of spec In-Reply-To: <4.3.2.7.2.20010227181931.00b96f58@funnel.cisco.com> 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 3/12 and 3/13 are not going to work for the design team teleconference. How about 3/14, noon-3PM EST? - Ralph From owner-dhcp-v6@bucknell.edu Wed Feb 28 09:54:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07959; Wed, 28 Feb 2001 09:54:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1SEnKL26058; Wed, 28 Feb 2001 09:49:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1SEn8L16310 for ; Wed, 28 Feb 2001 09:49:09 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29408 for ; Wed, 28 Feb 2001 06:49:06 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA21510 for ; Wed, 28 Feb 2001 15:49:04 +0100 (MET) Date: Wed, 28 Feb 2001 15:48:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: A proposal for DHCPv6 reconfiguration To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.2.7.2.20010227181222.03515838@mail.bucknell.edu> 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 > Reliable unicast transmission can be managed through the use of the > transaction-id. The server includes a unique transaction ID in each > unicast Reconfigure-init message. The client responds to the first > Reconfigure-init message it receives, copying the transaction ID into > the Reply message the client sends to the server, and ignores all > subsequent Reconfigure-init messages with the same transaction ID. I assume you mean "with the same transaction ID from the same DHCP server" in the last sentence. > This behavior causes the client to ignore duplicate copies of a single > Reconfigure-init message. If the server does not receive a Reply to > the Reconfigure-init with a matching transaction ID, the server can > try again by transmitting a new Reconfigure-init with a new > transaction ID. The new transaction ID will cause the client to start > the reconfiguration process again, in case the client did not receive > earlier Reconfigure-init messages or the server did not receive the > client's Reply. The delay before a server retries with a new > Reconfigure-init, the number of times the server should retry before > giving up and the server's action when it can't reach a client are > TBD. This seems a bit strange (but I don't have an alternate proposal) - are we really chartering new territory here? The strange part is that the server needs on retransmit strategy for a lost reconfigure-init (retransmit with same ID) and a different retransmit strategy for a lost reply (retransmit with a new ID). And of course the server can't tell which packet was lost. Will the latter part (use a new transaction id) be limited to unicast? Assuming the above is limited to unicast, what is the harm in the client keeping a copy of the last reply and retransmitting that reply when it sees a reconfigure-init which matches the last transaction ID? Then the server can have a simpler retransmit strategy for the unicast case. > For reconfiguration using multicast, the server multicasts an initial > message Reconfigure-init several times with the same transaction ID. > The number of retransmissions and the delay between retransmissions is > TBD. The client behavior is the same as in the unicast > Reocnfigure-inti message: each client in the multicast group to which > the Reconfigure-init message was transmitted responds to first message > it receives (not necessarily the first message transmitted by the > server) and ignores all other Reconfigure-init messages with the same > transaction ID. The server maintains a list of those clients that > have responded to the multicast Reconfigure-init message. After the > multicast Reconfigure-init messages have been transmitted, the server > reverts to unicast with new transaction ID for clients that have not > responded respond. That's fine. > To reduce the number of simultaneous Replies recieved by a server, > the server can include a delay parameter in the Reconfigure-init > message. Clients then choose random time between 0 and the > delay parameter to respond with a Reply message. I think the delay parameter should be mandatory in the multicast case. I wonder if we should suggest a default value for the delay the server should send in this parameter (e.g. * N milliseconds) Erik From owner-dhcp-v6@bucknell.edu Wed Feb 28 12:05:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13473; Wed, 28 Feb 2001 12:05:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1SH0pL00320; Wed, 28 Feb 2001 12:00:51 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1SH0hL11180 for ; Wed, 28 Feb 2001 12:00:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-156.cisco.com [161.44.133.156]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA27052; Wed, 28 Feb 2001 12:00:26 -0500 (EST) Message-Id: <4.3.2.7.2.20010228074126.02f47ff8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Feb 2001 07:45:18 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: A proposal for DHCPv6 reconfiguration Cc: DHCPv6 discussion list In-Reply-To: <78B1387745A15C46A7A727F2670D4A688C5892@DF-MILO.platinum.co rp.microsoft.com> 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 05:21 PM 2/27/2001 -0800, Thirumalesh Bhat wrote: >Ralph, thanks for driving this draft. I have a couple of questions >regarding the paragraphs below: > >First: > >When the server has a complete list of the clients to be > reconfigured, the server will know reliably that each > client has either been reconfigured exactly once or has > not responded to the server's reconfiguration request. > >What is meant by "complete list of clients to be reconfigured?". In the most general sense, the list of clients is completely specified. It may be all of the clients the server has a record of, an administrator specified list of clients, all clients that are attached to a link or ??? > Is this >something that is implementation specific? No. > For example, the system >administrator might want to specify that clients in subnet should be >reconfigured. Or is this all the clients that are present in the DHCP >Server database? Either. In contrast, if the server is handing out configuration parameters without assigning addresses, it may not have a complete list of the clients to be reconfigured. >Second: > > Clients and servers must be able to authenticate > Reconfigure-init messages, to avoid denial-of-service > attacks > > How do the clients and servers authenticate reconfigure-init messages? >Is this based on XID? If this is not based on XID, we need a scheme >where there is no user interaction at all. The clients and servers will use some form of DHCPv6 authentication (the mechanism for DHCPv6 authentication is TBD). - Ralph From owner-dhcp-v4@bucknell.edu Wed Feb 28 12:28:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15054 for ; Wed, 28 Feb 2001 12:28:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1SHF8L08915; Wed, 28 Feb 2001 12:15:08 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1SHEqL06066 for ; Wed, 28 Feb 2001 12:14:52 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1SH7Sv29935 for ; Wed, 28 Feb 2001 09:07:36 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: Re: why authenticate with DHCP? Date: Wed, 28 Feb 2001 09:16:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Are you assuming that all link layers will interface to AAA? Actually, network access does not interface to AAA directly. NASes act as gateways. So I don't think that this is a AAA question, it's a network access question. AAA can be made to work, regardless of the layer at which access control is enforced. >is it necessarily the right place to do it for all networks? I guess the answer to that depends on the ability to make a case for new MAC layers. I gather that 3G has investigated use of PPP or IEEE 802 framing, and concluded that this would not work. Can you share some of the reasoning behind that? I would note that in general, there seems to be a trend towards decreased MAC layer diversity. Just as we are moving to an IP Everywhere world, there is now movement towards Ethernet everywhere. So just as IP will displace IPX, AppleTalk, NetBEUI and SNA, so too will Ethernet displace Token Ring, ATM, FDDI, ARCnet and SONET. That doesn't mean that creating a new MAC is unjustified; it just means that it's bucking a trend and needs to be thought through carefully. Will someone at the BURP BOF be taking about 3G MAC layers? >What about non-802.11 networks? I think there is some confusion about where authentication occurs in 802.11 and other IEEE 802 technologies. IEEE 802.1X authentication occurs above the 802.1 MAC layer, which means that it can be used by any IEEE 802 technology, including Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11), PAN (802.16), etc. In IEEE 802.11b, authentication occurs below the 802.1 MAC layer. That is, WEP v1.0 packets are not visible to a conventional sniffer operating in promiscuous mode, although special 802.11 sniffers can get at it. This wasn't a smart thing to do because it requires changes to NIC and Access Point firmware in order to fix security bugs or add a new authentication method. The current intention is to move the authentication function above the MAC layer in WEP v2.0. > What about 3G networks? I'm not familiar enough with the 3G physical and data link proposals to give an opinion. But if 3G can honor the IEEE 802 hard and soft invariants, then it is a candidate for use of the IEEE 802.1 MAC, regardless of what the PHY is. Hard invariants: Nonduplication, Sequential delivery Soft invariants: Low delay, high bandwidth, low error rate Note that 802.11 honors these invariants even though it operates over the airwaves. The low error rate soft invariant (and sequential delivery) is honored via ARQ, and could conceivably be honored by other methods as well (e.g. FEC). The "low delay" invariant is relative; I've seen 802.11 installations with delay of > 200 ms that still function. "High bandwidth" was said to apply to the initial 802.11 implementations running at 1-2 Mbps, and I've seen applications using WAN mini-port drivers (e.g. latest Metricom cards) run fine at 128 Kbps speeds. So "high bandwidth" is somewhat relative too. >Why not provide means of doing this at a higher layer, for instance DHCP? I think that the architecture issues (layer 3/4 vs. layer 2) should be kept separate from the implementation issues (DHCP vs. alternative protocols). We might decide that layer 3 or layer 4 authentication makes sense in some cases, but that wouldn't necessarily imply DHCP as a solution. I'm not fond of using authenticated DHCP for access control because it wasn't developed to handle that scenario. After all, since a host can always choose a static address, authenticated DHCP by itself can't function as an access control mechanism. You need another mechanism, such as layer 3 filtering, in addition. See comments below relating to state requirements. Since George has expressed frustration that I always seem to be answering questions with more questions, I thought I'd keep up the tradition ;) Here are the questions that you'd need to answer in order to justify doing authentication at layer 3 or above: 1. Is there a compelling reason to invent a new MAC layer rather than just reusing PPP and IEEE 802? 2. Are we providing port access control, machine access control or user access control? Note that this is a separate issue from whether the identity claimed is that of a machine, user or group. Port access control requires the least state, since the maximum state required is in proportion to the number of ports on the NAS. Machine access control requires state for the maximum number of machines that can be connected to a NAS. If the NAS supports LAN technologies, then the number of machines can be considerably larger than the number of ports. For example, if we need to authentication every node on a LAN at layer 3, we could end up with thousands of nodes in the filter table; this could impact throughput and increase cost. The state requirements for user access control are even larger -- you could have multiple users per machine. Since state implies more hardware and higher cost as well as speed penalties, low cost/high speed devices have tended to support only port-based access control, which is the model implicitly assumed in PPP and 802.1X. 3. If authentication is done at layer 3, how do we deal with multi-protocol support? I am not thinking of AppleTalk, IPX, etc. so much as both IPv4 and IPv6. Do we have an authentication per protocol, or can one authentication be done that applies to all protocols? If authentication is done at layer 4, do we authenticate all applications? If so, how would this differ from an application layer authentication framework such as SASL? From owner-dhcp-v6@bucknell.edu Wed Feb 28 13:01:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16523; Wed, 28 Feb 2001 13:01:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1SHwKL11793; Wed, 28 Feb 2001 12:58:20 -0500 (EST) Received: from rdroms-w2k.bucknell.edu (ch2-dhcp133-156.cisco.com [161.44.133.156]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1SHw2L09621 for ; Wed, 28 Feb 2001 12:58:06 -0500 (EST) Message-Id: <4.3.2.7.2.20010228123553.00b52a98@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Feb 2001 12:57:30 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: A proposal for DHCPv6 reconfiguration In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20010227181222.03515838@mail.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 At 03:48 PM 2/28/2001 +0100, Erik Nordmark wrote: > > Reliable unicast transmission can be managed through the use of the > > transaction-id. The server includes a unique transaction ID in each > > unicast Reconfigure-init message. The client responds to the first > > Reconfigure-init message it receives, copying the transaction ID into > > the Reply message the client sends to the server, and ignores all > > subsequent Reconfigure-init messages with the same transaction ID. > >I assume you mean "with the same transaction ID from the same DHCP server" >in the last sentence. Yes. I'll make that clear in the spec. > > This behavior causes the client to ignore duplicate copies of a single > > Reconfigure-init message. If the server does not receive a Reply to > > the Reconfigure-init with a matching transaction ID, the server can > > try again by transmitting a new Reconfigure-init with a new > > transaction ID. The new transaction ID will cause the client to start > > the reconfiguration process again, in case the client did not receive > > earlier Reconfigure-init messages or the server did not receive the > > client's Reply. The delay before a server retries with a new > > Reconfigure-init, the number of times the server should retry before > > giving up and the server's action when it can't reach a client are > > TBD. > >This seems a bit strange (but I don't have an alternate proposal) - are >we really chartering new territory here? >The strange part is that the server needs on retransmit strategy for >a lost reconfigure-init (retransmit with same ID) and a different >retransmit strategy for a lost reply (retransmit with a new ID). >And of course the server can't tell which packet was lost. The server always uses a new transaction-ID when retransmitting a unicast Reconfigure-init. The client ignores Reconfigure-init messages with the same transaction-ID to filter (unintentional; i.e. spuriously generated by network elements) duplicates of the original Reconfigure-init message. This issue was raised during the WG discussion in San Diego. >Will the latter part (use a new transaction id) be limited to >unicast? No - it applies to both unicast and multicast. When using multicast, the server transmits a some number of Reconfigure-init messages on a schedule that uses exponential backoff (this machinery is in the -17 rev of the spec). From the WG discussion in San Diego, the motivation for using multicast is the case in which the server doesn't have a complete list of clients. In this case, the server can't guarantee reliable delivery - so the suggestion was to provide some measure of reliability through retransmission of the same message in the multicast case. One design goal here is to avoid the need for the client to differentiate between unicast and multicast Reconfigure-init messages. After I thought about the problem for a while - considering both the retransmission and message duplication cases - this design seemed like an elegant way to * avoid redundant receonfiguration triggered by duplicate Reconfigure-init messages * allow reliable reconfiguration through retransmission of unicast Reconfigure-init messages * allow for extra reliability through retransmission of multicast Reconfigure-init messages without causing some clients to reconfigure multiple times * simplify the client by specifying the same behavior in response to both unicast and multicast Reconfigure-init messages >Assuming the above is limited to unicast, what is the harm in the client >keeping a copy of the last reply and retransmitting that reply >when it sees a reconfigure-init which matches the last transaction ID? >Then the server can have a simpler retransmit strategy for the unicast case. How does the client differentiate between an intentional retransmission and a duplicated Reconfigure-init? The client should remain silent when it receives a duplicated Reconfigure-init. > > For reconfiguration using multicast, the server multicasts an initial > > message Reconfigure-init several times with the same transaction ID. > > The number of retransmissions and the delay between retransmissions is > > TBD. The client behavior is the same as in the unicast > > Reocnfigure-init message: each client in the multicast group to which > > the Reconfigure-init message was transmitted responds to first message > > it receives (not necessarily the first message transmitted by the > > server) and ignores all other Reconfigure-init messages with the same > > transaction ID. The server maintains a list of those clients that > > have responded to the multicast Reconfigure-init message. After the > > multicast Reconfigure-init messages have been transmitted, the server > > reverts to unicast with new transaction ID for clients that have not > > responded respond. > >That's fine. > > > To reduce the number of simultaneous Replies recieved by a server, > > the server can include a delay parameter in the Reconfigure-init > > message. Clients then choose random time between 0 and the > > delay parameter to respond with a Reply message. > >I think the delay parameter should be mandatory in the multicast case. >I wonder if we should suggest a default value for the delay the server >should send in this parameter (e.g. * N >milliseconds) OK, making the delay mandatory sounds sensible. - Ralph From owner-dhcp-v4@bucknell.edu Wed Feb 28 14:00:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19119 for ; Wed, 28 Feb 2001 14:00:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f1SIplL31496; Wed, 28 Feb 2001 13:51:47 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f1SIpTL25501 for ; Wed, 28 Feb 2001 13:51:31 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA03286 for ; Wed, 28 Feb 2001 10:51:03 -0800 (PST) Message-Id: <4.1.20010228133753.00a1a1e0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 28 Feb 2001 13:40:36 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: why authenticate with DHCP? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 09:16 AM 02/28/2001 -0800, Bernard Aboba wrote: > >I would note that in general, there seems to be a trend towards >decreased MAC layer diversity. Just as we are moving to an IP >Everywhere world, there is now movement towards Ethernet >everywhere. So just as IP will displace IPX, AppleTalk, >NetBEUI and SNA, so too will Ethernet displace Token Ring, ATM, >FDDI, ARCnet and SONET. This market trend is not essential to the rest of the argument for the reason included below. (Not that I disagree with your observation.) >IEEE 802.1X authentication occurs above the 802.1 MAC layer, which >means that it can be used by any IEEE 802 technology, including >Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11), >PAN (802.16), etc.