From owner-dhcp-v4@bucknell.edu Sun Apr 1 21:55:43 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18898 for ; Sun, 1 Apr 2001 21:55:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f321mUe03349; Sun, 1 Apr 2001 21:48:31 -0400 (EDT) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f321mQe09325 for ; Sun, 1 Apr 2001 21:48:26 -0400 (EDT) Received: from mr7.exu.ericsson.se. (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f321m1803389 for ; Sun, 1 Apr 2001 20:48:01 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f321m1j26799 for ; Sun, 1 Apr 2001 20:48:01 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Apr 01 20:48:00 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 20:48:00 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694F989D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) Date: Sun, 1 Apr 2001 20:47:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB16.F20DD000" 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_01C0BB16.F20DD000 Content-Type: text/plain; charset="iso-8859-1" Barr: While I like these in theory, I'm not sure how practical they will be. Recalling existing options, no matter how little implemented, won't be easy because older implementations will always exist. And, if a client used the old form of the option but the server gave out the new one (or vice versa), you could easily have problems. - Bernie -----Original Message----- From: Richard Barr Hibbs [mailto:rbhibbs@ultraDNS.com] Sent: Friday, March 30, 2001 2:59 PM To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) > -----Original Message----- > From: Ralph Droms > Sent: Friday, March 30, 2001 10:05 AM > > It's not clear we are in an emergency yet. There are 10-15 option codes > that were reserved before the current option assignment rules > (BCP 43, RFC 2939) were put in place but were never formally assigned to > an option (usually because the option was never accepted as a Proposed > Standard). I started to go through the list of assigned option codes once > upon a time but never followed through to submit a list to IANA of codes > that could be reassigned. > I've forgotten now how long ago I proposed two possible ways of obtaining relief that were rejected by voice vote at a Working Group meeting, but I'm going to throw them out again to the mailing list. 1. Establish "Sunset" rules for DHCPv4 Options Certain options are absolutely required by the base protocol, but many are simply convenience items. Examples include things like "Default IRC Server." For non-mandatory options, IANA could establish a sunset date, say 5 years after adoption of the option code. At the sunset date, any option which could not muster support (based on actual usage) would be retired, and its code available for reuse. This approach has a number of problems, as pointed out by Thomas Narten, not the least of which is burdening IANA with yet another task, and the necessity of making each non-mandatory option a separate RFC to have individual control over the assigned option codes. It has the distinct advantage of preventing the v4 option space from becoming bloated over time with unused and forgotten options. 2. Establish a "Demonstrated Use" Rule for New Options When a new option is proposed in an Internet-Draft, it's status would be "Experimental" rather than "Standards Track" until a minimum number of interoperable implementations (for example, three) could be demonstrated. Only then would the option be promoted to "Standards Track" status, thus permitting easy reclamation and reuse of options that seemed like a good idea, but which don't make it into actual usage. This has the disadvantage of lengthening the document cycle, but it does have a built-in regulatory mechanism in the form of demonstrable, interoperable implementations. ----- Neither of these proposals diminishes the value of considering how we could significantly enlarge the v4 option space, but there is also the ugly question of should be trying to extend the useful life of DHCPv4 at all? Doesn't that reduce the likelihood of DHCPv6 being adopted widely? That is also something we should perhaps debate here. --Barr Hibbs UltraDNS Corporation ------_=_NextPart_001_01C0BB16.F20DD000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCP Option Tag Exhaustion (1..127)

Barr:

While I like these in theory, I'm not sure how = practical they will be. Recalling existing options, no matter how = little implemented, won't be easy because older implementations will = always exist. And, if a client used the old form of the option but the = server gave out the new one (or vice versa), you could easily have = problems.

- Bernie

-----Original Message-----
From: Richard Barr Hibbs [mailto:rbhibbs@ultraDNS.com]
Sent: Friday, March 30, 2001 2:59 PM
To: DHCPv4 discussion list
Subject: RE: DHCP Option Tag Exhaustion = (1..127)




> -----Original Message-----
> From: Ralph Droms
> Sent: Friday, March 30, 2001 10:05 AM

>
> It's not clear we are in an emergency = yet.  There are 10-15 option codes
> that were reserved before the current option = assignment rules
> (BCP 43, RFC 2939) were put in place but were = never formally assigned to
> an option (usually because the option was never = accepted as a Proposed
> Standard).  I started to go through the = list of assigned option codes once
> upon a time but never followed through to = submit a list to IANA of codes
> that could be reassigned.
>

I've forgotten now how long ago I proposed two = possible ways of obtaining
relief that were rejected by voice vote at a Working = Group meeting, but I'm
going to throw them out again to the mailing = list.

1.  Establish "Sunset" rules for = DHCPv4 Options

Certain options are absolutely required by the base = protocol, but many are
simply convenience items.  Examples include = things like "Default IRC
Server."  For non-mandatory options, IANA = could establish a sunset date, say
5 years after adoption of the option code.  At = the sunset date, any option
which could not muster support (based on actual = usage) would be retired, and
its code available for reuse.

This approach has a number of problems, as pointed = out by Thomas Narten, not
the least of which is burdening IANA with yet = another task, and the
necessity of making each non-mandatory option a = separate RFC to have
individual control over the assigned option = codes.

It has the distinct advantage of preventing the v4 = option space from
becoming bloated over time with unused and forgotten = options.


2.  Establish a "Demonstrated Use" = Rule for New Options

When a new option is proposed in an Internet-Draft, = it's status would be
"Experimental" rather than "Standards = Track" until a minimum number of
interoperable implementations (for example, three) = could be demonstrated.
Only then would the option be promoted to = "Standards Track" status, thus
permitting easy reclamation and reuse of options = that seemed like a good
idea, but which don't make it into actual = usage.

This has the disadvantage of lengthening the document = cycle, but it does
have a built-in regulatory mechanism in the form of = demonstrable,
interoperable implementations.

-----

Neither of these proposals diminishes the value of = considering how we could
significantly enlarge the v4 option space, but there = is also the ugly
question of should be trying to extend the useful = life of DHCPv4 at all?
Doesn't that reduce the likelihood of DHCPv6 being = adopted widely?  That is
also something we should perhaps debate here.

--Barr Hibbs
  UltraDNS Corporation

------_=_NextPart_001_01C0BB16.F20DD000-- From owner-dhcp-v6@bucknell.edu Sun Apr 1 23:22:07 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02428; Sun, 1 Apr 2001 23:22:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f323Ige03348; Sun, 1 Apr 2001 23:18:42 -0400 (EDT) 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 f323IXe05248 for ; Sun, 1 Apr 2001 23:18:33 -0400 (EDT) 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 f323IVg03447 for ; Sun, 1 Apr 2001 22:18:31 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 1 Apr 2001 22:18:12 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Sun, 1 Apr 2001 22:18:12 -0500 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu, aboba@internaut.com, Jim.Bound@nokia.com, deering@cisco.com, erik.guttman@sun.com, itojun@iijlab.net, hinden@IPRG.NOKIA.COM, jinmei@isl.rdc.toshiba.com, onoe@sm.sony.co.jp, hesham.soliman@ericsson.com Subject: RE: draft-ietf-ipngwg-dns-discovery-00.txt Date: Sun, 1 Apr 2001 22:18:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 just as a note I am in full agreement with my coauthors on the design team. /jim > -----Original Message----- > From: ext Dave Thaler [mailto:dthaler@Exchange.Microsoft.com] > Sent: Thursday,March 29,2001 5:16 PM > To: Bernie Volz (EUD) > Cc: dhcp-v6@bucknell.edu; aboba@internaut.com; jim.bound@nokia.com; > deering@cisco.com; erik.guttman@sun.com; itojun@iijlab.net; > hinden@iprg.nokia.com; jinmei@isl.rdc.toshiba.com; onoe@sm.sony.co.jp; > hesham.soliman@ericsson.com; Dave Thaler > Subject: RE: draft-ietf-ipngwg-dns-discovery-00.txt > > > To add to what Erik said... > > > Time to Deploy - It will take a little time since we need to > > clean up the DHCPv6 specification. This should not take long > > (and likely less time than developing a new mechanism and > > working out the issues with that). Routers and servers will > > need to have new software deployed (as well as clients, but > > hopefully DHCPv6 will become standard on them anyway). We > > could always define DHCPv6 operation for non-addresses now > > and work out the address issues in parallel. > > This was one of the factors. DHCPv6 needs both protocol > specification work by the DHC WG, and new code on DNS Servers. > The approach the team recommended requires no protocol > specification work by any other WG, and no new code on > DNS Servers. > > > Business Motivation - This is exactly why DHCPv6 would be a > > better approach. It will benefit DHCPv6 as well. > > The business motivation for the DNS approach is stronger > than the business motivation for the DHCP approach. > (E.g. a DNS server vendor would prefer the DNS approach > since it's less work.) > > > Fate Sharing - Don't believe so. > > For DNS server discovery, there's a potential fate sharing > issue if the mini-DHCP server isn't tightly integrated > with the DNS server. (For example, if the DNS server > process dies, but the mini-DHCP server continues to > give out the DNS server's address, there's a problem. > Similarly, if the DNS server is handling requests, > but the mini-DHCP server stops responding, there's > a problem.) Using DNS queries themselves has > optimal fate sharing properties. > > > Scenarios - Hosts connected over an NBMA link: This may be a > > problem but then DHCPv6 would suffer from the same problem. > > The team's recommended solution works fine in this scenario. > > -Dave > From owner-dhcp-v4@bucknell.edu Mon Apr 2 10:37:29 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12274 for ; Mon, 2 Apr 2001 10:37:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f32EU2e25052; Mon, 2 Apr 2001 10:30:03 -0400 (EDT) Received: from mothra.regscan.com ([209.173.83.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f32ETKe16449 for ; Mon, 2 Apr 2001 10:29:21 -0400 (EDT) Received: from jaxee ([209.173.83.19]) by mothra.regscan.com (Post.Office MTA v3.5.3 release 223 ID# 0-68616U300L2S100V35) with SMTP id com for ; Mon, 2 Apr 2001 10:27:08 -0400 Message-ID: <007001c0bb81$48cd6710$1353add1@regscan.com> From: ehepler@regscan.com (Eric Hepler) To: DHCPv4 discussion list Subject: DHCP Implementation Advice Date: Mon, 2 Apr 2001 10:29:11 -0400 Organization: RegScan, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C0BB5F.C1A7F0F0" 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: ehepler@regscan.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_006D_01C0BB5F.C1A7F0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm new to this list, please bare with me or point me in the right = direction... My organization would like to begin using DHCP with private addressing, = rather than statically assigning routable addresses. Now while I'm = confident I can implement the needed methods, I'm having some difficulty = getting everything to work together. So if anyone can offer any = assistance, it would be greatly appreciated. Here's my scenario. 1. We are currently using a class c from our T-1 provider, that we will = be returning in the next 21 days when we move to a new provider in a new = building. We do have the option of giving static routable addresses out = again, but we'd like to move into Private address assignment with DHCP. 2. Our network consists of a Primary Domain Controller on Windows NT = 4.0. 99% of all workstations are Windows 95 or 98. 3. The new building we move into is probably going to span over 254 = required IP addresses very quickly... First question, how do I get DHCP to span multiple networks (specify = a scope of 192.168.1.1 - 192.168.254.254, subnet mask 255.255.0.0?)? 4. I was able to get a machine to distribute the IP lease information, = however, clients couldn't log onto the PDC nor could they get out on the = gateway I assigned. Now I assume the gateway problem is just a matter = of telling the router to route 192.168.0.0 to the serial IP on the = router (maybe I'm wrong?), but why would the IP address information = prevent them from logging onto the network? Thanks for any assistance anyone can offer. _________________________________________ Eric T. Hepler - Systems Programmer RegScan, Inc. - http://www.regscan.com ehepler@regscan.com - 570.323.1010 x1305 Mobile: 570.320.6342 - eFax: 561.760.0323 ------=_NextPart_000_006D_01C0BB5F.C1A7F0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm new to this list, please bare with = me or point=20 me in the right direction...
 
My organization would like to begin = using DHCP with=20 private addressing, rather than statically assigning routable=20 addresses.  Now while I'm confident I can implement = the needed=20 methods, I'm having some difficulty getting everything to work = together. =20 So if anyone can offer any assistance, it would be greatly = appreciated. =20 Here's my scenario.
 
1. We are currently using a class c = from our T-1=20 provider, that we will be returning in the next 21 days when we move to = a new=20 provider in a new building.  We do have the option of giving static = routable addresses out again, but we'd like to move into Private address = assignment with DHCP.
 
2. Our network consists of a Primary = Domain=20 Controller on Windows NT 4.0.  99% of all workstations are Windows = 95 or=20 98.
 
3. The new building we move into is = probably going=20 to span over 254 required IP addresses very quickly...
    First question, how = do I get=20 DHCP to span multiple networks (specify a scope of 192.168.1.1 -=20 192.168.254.254, subnet mask 255.255.0.0?)?
 
4. I was able to get a machine to = distribute the IP=20 lease information, however, clients couldn't log onto the PDC nor could = they get=20 out on the gateway I assigned.  Now I assume the gateway problem is = just a=20 matter of telling the router to route 192.168.0.0 to the serial IP on = the router=20 (maybe I'm wrong?), but why would the IP address information prevent = them from=20 logging onto the network?
 
Thanks for any assistance anyone can=20 offer.
 
_________________________________________
Eric=20 T. Hepler - Systems Programmer
RegScan, Inc. - http://www.regscan.com
ehepler@regscan.com - = 570.323.1010=20 x1305
Mobile: 570.320.6342 - eFax: 561.760.0323
 
 
------=_NextPart_000_006D_01C0BB5F.C1A7F0F0-- From owner-dhcp-v4@bucknell.edu Mon Apr 2 13:08:08 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21089 for ; Mon, 2 Apr 2001 13:08:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f32H1be13294; Mon, 2 Apr 2001 13:01:37 -0400 (EDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f32H1Le01095 for ; Mon, 2 Apr 2001 13:01:21 -0400 (EDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id KAA21110 for ; Mon, 2 Apr 2001 10:01:20 -0700 Received: from knock_noc.nebula.washington.edu (D-128-95-135-203.dhcp2.washington.edu [128.95.135.203]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.12) with ESMTP id KAA03737 for ; Mon, 2 Apr 2001 10:01:20 -0700 Date: Mon, 2 Apr 2001 10:01:20 -0700 (Pacific Daylight Time) From: Amel Caldwell To: DHCPv4 discussion list Subject: problem with DHCP relay behaviour change in Cisco IOS Message-ID: X-X-Sender: amelc@shivams.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: amelc@cac.washington.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello-- I have been looking at a problem that we have been experiencing with some older (but critical) DHCP clients since we performed an IOS upgrade on one of our routers. First a little background. On campus, we have a groups of people (who support thousans of machines) who use a Lan Manager dhcp client while booting a machine to have it login to a central facilitty and basically configure itself with standard tools/configs. We also have a home-grown DHCP server that currently supports on the order of 15,000 concurrent leases. This has all been working with no changes to the DHCP client or the server for 3 years or more. Now, the problem. We upgraded a Cisco router from 12.0 code to 12.1, and since then these clients have been failing while other clients continue to work fine. I have sniffed the DHCP transactions and have tried a few 12.1 releases (12.1(3), 12.1(5), 12.1(6) and 12.1(7) ) and think I know why the client is not working. In the packets I have sniffed, the client sets the broadcast flag. On 12.0 code, the DHCP Offer comes back with the source address as the address of the DHCP server and the Destination address of 255.255.255.255; on 12.1 code the DHCP Offer comes back with the source address of the gateway (or the relay agent) and a destination of the network's broacast address (in this case 128.208.20.255). I think this is broken behaviour; if the client is not capable of unicasting without binding to its offered address, it is not going to know what network is on and won't respond to anything but an all 1's broadcast. Right? I plan on opening a TAC case on this, but wanted to get feedback here first. Regards, Amel Caldwell UW NDC Network Engineering Services phone: 206-685-6205 fax: 206-685-4044 email: amelc@cac.washington.edu From owner-dhcp-v4@bucknell.edu Mon Apr 2 17:51:30 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02409 for ; Mon, 2 Apr 2001 17:51:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f32Lice08323; Mon, 2 Apr 2001 17:44:39 -0400 (EDT) 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 f32LiJe03683 for ; Mon, 2 Apr 2001 17:44:20 -0400 (EDT) Received: from grosse.bisbee.fugue.com (az-ben-pm3-2-19.ppp.theriver.com [206.25.50.19]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2V9OeE28544; Sat, 31 Mar 2001 01:24:41 -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 f32MdtI00358; Mon, 2 Apr 2001 15:39:55 -0700 (MST) Message-Id: <200104022239.f32MdtI00358@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: problem with DHCP relay behaviour change in Cisco IOS In-Reply-To: Message from Amel Caldwell of "Mon, 02 Apr 2001 10:01:20 MST." Date: Mon, 02 Apr 2001 15:39:55 -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 think this is broken behaviour; if the client is not > capable of unicasting without binding to its offered address, it is not going > to know what network is on and won't respond to anything but an all 1's > broadcast. Right? That's right - it should be sending the packet to 255.255.255.255. The source address change is correct, however, and is probably not what is causing your problem. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Apr 2 18:06:35 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02653 for ; Mon, 2 Apr 2001 18:06:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f32M4Fe24052; Mon, 2 Apr 2001 18:04:15 -0400 (EDT) Received: from cisco.com (sigma.cisco.com [171.69.26.43]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f32M48e30454 for ; Mon, 2 Apr 2001 18:04:08 -0400 (EDT) Received: (from irfan@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA24800; Mon, 2 Apr 2001 15:03:52 -0700 (PDT) Date: Mon, 2 Apr 2001 15:03:51 -0700 From: Irfan Ashraf To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: problem with DHCP relay behaviour change in Cisco IOS Message-ID: <20010402150351.D23436@sigma.cisco.com> References: <200104022239.f32MdtI00358@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200104022239.f32MdtI00358@grosse.bisbee.fugue.com>; from mellon@nominum.com on Mon, Apr 02, 2001 at 03:39:55PM -0700 Reply-To: irfan@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Someone from Cisco followed up on this. I believe Amel Caldwell was happy with the answer. Apparently the box was relaying to the configured broadcast address of the interface. The config command: "ip dhcp limited-broadcast-address", worked around the config'd address. -Irfan On Mon, Apr 02, 2001 at 03:39:55PM -0700, Ted Lemon wrote: > > > I think this is broken behaviour; if the client is not > > capable of unicasting without binding to its offered address, it is not going > > to know what network is on and won't respond to anything but an all 1's > > broadcast. Right? > > That's right - it should be sending the packet to 255.255.255.255. > The source address change is correct, however, and is probably not > what is causing your problem. > > _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Apr 2 18:41:04 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03143 for ; Mon, 2 Apr 2001 18:41:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f32MYbe23598; Mon, 2 Apr 2001 18:34:37 -0400 (EDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f32MYOe13081 for ; Mon, 2 Apr 2001 18:34:24 -0400 (EDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id PAA27141 for ; Mon, 2 Apr 2001 15:34:20 -0700 Received: from knock_noc.nebula.washington.edu (D-128-95-135-203.dhcp2.washington.edu [128.95.135.203]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.12) with ESMTP id PAA17670 for ; Mon, 2 Apr 2001 15:34:19 -0700 Date: Mon, 2 Apr 2001 15:34:19 -0700 (Pacific Daylight Time) From: Amel Caldwell To: DHCPv4 discussion list Subject: Re: problem with DHCP relay behaviour change in Cisco IOS In-Reply-To: Message-ID: X-X-Sender: amelc@shivams.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: amelc@cac.washington.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi-- Someone from Cisco sent me the following which has resolved my problems. >You should be able to configure "ip dhcp limited-broadcast-address" on >the router, to force it to broadcast the forwarded DHCP packets to >255.255.255.255, ignoring the configured broadcast address on the >interface. This command is available starting in 12.1(3.1) versions. > Regards Amel On Mon, 2 Apr 2001, Amel Caldwell wrote: >Hello-- > >I have been looking at a problem that we have been experiencing with some >older (but critical) DHCP clients since we performed an IOS upgrade on one of >our routers. > >First a little background. On campus, we have a groups of people (who support >thousans of machines) who use a Lan Manager dhcp client while booting a >machine to have it login to a central facilitty and basically configure itself >with standard tools/configs. We also have a home-grown DHCP server that >currently supports on the order of 15,000 concurrent leases. This has all >been working with no changes to the DHCP client or the server for 3 years or >more. > >Now, the problem. We upgraded a Cisco router from 12.0 code to 12.1, and >since then these clients have been failing while other clients continue to >work fine. I have sniffed the DHCP transactions and have tried a few 12.1 >releases (12.1(3), 12.1(5), 12.1(6) and 12.1(7) ) and think I know why the >client is not working. > >In the packets I have sniffed, the client sets the broadcast flag. On 12.0 >code, the DHCP Offer comes back with the source address as the address of the >DHCP server and the Destination address of 255.255.255.255; on 12.1 code the >DHCP Offer comes back with the source address of the gateway (or the relay >agent) and a destination of the network's broacast address (in this case >128.208.20.255). I think this is broken behaviour; if the client is not >capable of unicasting without binding to its offered address, it is not going >to know what network is on and won't respond to anything but an all 1's >broadcast. Right? > >I plan on opening a TAC case on this, but wanted to get feedback here first. > >Regards, > >Amel Caldwell > >UW NDC Network Engineering Services >phone: 206-685-6205 fax: 206-685-4044 >email: amelc@cac.washington.edu > > From owner-dhcp-v6@bucknell.edu Tue Apr 3 19:18:51 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20074; Tue, 3 Apr 2001 19:18:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f33NFZe13055; Tue, 3 Apr 2001 19:15:35 -0400 (EDT) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f33NFQe30123 for ; Tue, 3 Apr 2001 19:15:32 -0400 (EDT) Received: from hpindbm.cup.hp.com (hpindbm.cup.hp.com [15.13.104.188]) by palrel3.hp.com (Postfix) with ESMTP id 7C4302AC for ; Tue, 3 Apr 2001 16:15:25 -0700 (PDT) Received: (from ebi@localhost) by hpindbm.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA23919 for dhcp-v6@bucknell.edu; Tue, 3 Apr 2001 16:15:24 -0700 (PDT) Date: Tue, 3 Apr 2001 16:15:24 -0700 From: ebi@cup.hp.com To: DHCPv6 discussion list Subject: Renw/Confirm messages Message-ID: <20010403161524.L14434@hpindbm.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, I have some questions regarding the rev 18 of the DHCPv6 draft. The confirm and the rebind messages are sent with the server address set to 0. The servers that receive it are supposed to return - Nobinding - Renw/ConfNoMatch - Unavail errors. There is a chance that the client can receive error messages from more than one server, as these (confirm/renew) messages are multicast. The section on client behaviour does not say how it should deal with this multiple error messages. What should be the right behaviour ? Should the server address be set to the server it received the IA from ? -- Regards, Ebi From owner-dhcp-v6@bucknell.edu Wed Apr 4 09:03:51 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17276; Wed, 4 Apr 2001 09:03:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34D16e10668; Wed, 4 Apr 2001 09:01:07 -0400 (EDT) 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 f34D0xe19192 for ; Wed, 4 Apr 2001 09:00:59 -0400 (EDT) Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f34D0wm15792 for ; Wed, 4 Apr 2001 08:00:58 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f34D0wa13831 for ; Wed, 4 Apr 2001 08:00:58 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Apr 04 08:00:57 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <21WFN7Y0>; Wed, 4 Apr 2001 08:00:57 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694F9A16@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Renw/Confirm messages Date: Wed, 4 Apr 2001 08:00:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BD07.490307D0" 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_01C0BD07.490307D0 Content-Type: text/plain; charset="iso-8859-1" My feeling on this is that we may want some more errors codes. I believe that the status could indicate: - The binding is valid (success) - The server has no information about the binding but the prefixes are valid (Nobinding?) - The server has no information about the binding but the prefixes are bad (??) - The server has no information, such as it may not be authorizative for the prefix(es) (?? - no response perhaps?) Depending on the status, the client would either (a) be done (success), (b) drop the addresses (bad prefixes status), or (c) wait for a short period of time for better information and if none received, continue using the addresses. This would let the client know quickly that it has moved to a new subnet or that it is still on the same subnet. Note that a CONFIRM might be better handled on networks with Router Advertisements by waiting for one of these. The "bad prefix" status is to handle cases where there are no routers. I think I provided a more detailed explaination of the above a few weeks ago. Please check the archive (www.dhcp.org has the links). - Bernie Volz -----Original Message----- From: ebi@cup.hp.com [mailto:ebi@cup.hp.com] Sent: Tuesday, April 03, 2001 7:15 PM To: DHCPv6 discussion list Subject: Renw/Confirm messages Hi, I have some questions regarding the rev 18 of the DHCPv6 draft. The confirm and the rebind messages are sent with the server address set to 0. The servers that receive it are supposed to return - Nobinding - Renw/ConfNoMatch - Unavail errors. There is a chance that the client can receive error messages from more than one server, as these (confirm/renew) messages are multicast. The section on client behaviour does not say how it should deal with this multiple error messages. What should be the right behaviour ? Should the server address be set to the server it received the IA from ? -- Regards, Ebi ------_=_NextPart_001_01C0BD07.490307D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Renw/Confirm messages

My feeling on this is that we may want some more = errors codes. I believe that the status could indicate:
- The binding is valid (success)
- The server has no information about the binding = but the prefixes are valid (Nobinding?)
- The server has no information about the binding = but the prefixes are bad (??)
- The server has no information, such as it may not = be authorizative for the prefix(es) (?? - no response perhaps?)

Depending on the status, the client would either (a) = be done (success), (b) drop the addresses (bad prefixes status), or (c) = wait for a short period of time for better information and if none = received, continue using the addresses.

This would let the client know quickly that it has = moved to a new subnet or that it is still on the same subnet.

Note that a CONFIRM might be better handled on = networks with Router Advertisements by waiting for one of these. The = "bad prefix" status is to handle cases where there are no = routers.

I think I provided a more detailed explaination of = the above a few weeks ago. Please check the archive (www.dhcp.org has = the links).

- Bernie Volz

-----Original Message-----
From: ebi@cup.hp.com [mailto:ebi@cup.hp.com]
Sent: Tuesday, April 03, 2001 7:15 PM
To: DHCPv6 discussion list
Subject: Renw/Confirm messages


Hi,

        I have = some questions regarding the rev 18 of the DHCPv6 draft.  = The
        confirm = and the rebind messages are sent with the server address set
        to = 0.  The servers that receive it are supposed to return

        =         =         - = Nobinding
        =         =         - = Renw/ConfNoMatch
        =         =         - = Unavail

        errors.  There  is a  chance  that  = the  client  can  receive  error
        messages  from  more  than  one  = server,  as  these  (confirm/renew)
        messages = are  multicast.  The section on client  behaviour  = does not
        say how = it should deal with this multiple error messages.

        What = should be the right  behaviour ?  Should the server  = address be
        set to = the server it received the IA from ? 

  
--
Regards,
Ebi

------_=_NextPart_001_01C0BD07.490307D0-- From owner-dhcp-v4@bucknell.edu Wed Apr 4 10:31:35 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20904 for ; Wed, 4 Apr 2001 10:31:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34ELUe24717; Wed, 4 Apr 2001 10:21:30 -0400 (EDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f34ELKe03801 for ; Wed, 4 Apr 2001 10:21:20 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 10:21:02 -0400 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Subject: implementations? Date: Wed, 4 Apr 2001 10:21:02 -0400 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 all, Has anyone implemented the authentication features in DHCP? private e-mail will do if you do not want to say on the list. Thanks George From owner-dhcp-v4@bucknell.edu Wed Apr 4 11:58:57 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24087 for ; Wed, 4 Apr 2001 11:58:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34Fpce20851; Wed, 4 Apr 2001 11:51:38 -0400 (EDT) Received: from styx.uwaterloo.ca (styx.uwaterloo.ca [129.97.105.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f34FpPe03969 for ; Wed, 4 Apr 2001 11:51:25 -0400 (EDT) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id f34Fp3d03939; Wed, 4 Apr 2001 11:51:03 -0400 Date: Wed, 4 Apr 2001 11:51:03 -0400 (EDT) From: Roop Mukherjee To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: implementations? 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 Yes, we have a prototype implementation of the authentication proposal of draft-mukherjee-dhc-dhcproam.txt. It was done by using the ISC DHCP implementation and radlib. The system could check for signatures, do challenge response and interface to a off-the-shelf RADIUS server. We tested the system with an AAA server (livingstone implementation). The whole thing was fairly simple and took less than a month. We though that these intial signs made it quite an attractive thing from the deployment point of view. I would be happy to provide more information if anyone is interested. -- Roop ________________________________________ On Wed, 4 Apr 2001, George Tsirtsis wrote: > Hi all, > > Has anyone implemented the authentication features in DHCP? private e-mail > will do if you do not want to say on the list. > > Thanks > George > ________________________________________ From owner-dhcp-v6@bucknell.edu Wed Apr 4 14:00:23 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27565; Wed, 4 Apr 2001 14:00:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34Huxe13615; Wed, 4 Apr 2001 13:56:59 -0400 (EDT) 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 f34Hure06718; Wed, 4 Apr 2001 13:56:54 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sj-dial-4-44.cisco.com [171.68.181.173]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05977; Wed, 4 Apr 2001 13:56:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20010404133654.031cefb8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Apr 2001 13:38:25 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from 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 Here are my draft minutes from the WG meeting. Please respond with additions, corrections or comments by 5PM, 4/6. - Ralph Summary of DHC WG meetings in Minneapolis. Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes Droms announced that the relay information option, load balancing and authentication specs have been accepted as draft standards. DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt The WG finds this option acceptable in principle; however, the specific format and encoding of data in the option is still an issue. Authors want simple ASCII text encoding of DNS name or dotted decimal IP address; WG recommends RFC1035 encoding for DNS name and binary encoding of IP address with flag to indicate which encoding is in use. WG has selected RFC1035 for other recent options. Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt This spec is ready for WG last call. The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Author will rev spec, changing "MUST implement" to "SHOULD implement"; spec will then we ready for WG last call. Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt This draft enables the CSR option as well as other options that may require more than 255 data bytes. Kim Kinnear will forward spec fixes to author. Next rev of spec will be ready for WG last call. The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt This draft depends on the long DHCP options draft. Bernie Volz will forward spec fixes to author. Next rev of spec will be ready for WG last call. DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt Kinnear will review last call comments and issue concerning addresses in protocol (does NAT affect server-server identification using IP addresses?). Next rev of spec will be ready for WG last call. DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Spec requires further work with input from WG. Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt This spec is ready for WG last call. DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt These specs will be taken on as DHC WG work items. Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Author will work with Droms and Schnizlein to revise draft. Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt This spec will be taken on as a DHC WG work item. ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Report from DDDT (Dynamic DNS Design Team) Bernard Aboba, 15 minutes The DDDT has developed an "Analysis of DNS Server Discovery Mechanisms for IPv6" . One of the discovery mechanisms uses DHCP messages and semantics to pass DNS server information to clients. Aboba presented a summary of the report for the information of the DHC WG. Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt - Review of changes in current draft - Review of design team teleconference Summary of changes: * Added new messages: Confirm, Renew, Rebind, Decline * Uniform format for all client-server messages * Clarified relay agent forwarding * Advertise messages include offered addresses for client selection * Clients multicast all messages to accommodate relay agent options; will add new option to allow server control of use of unicast * New Reconfigure-init semantics - "trigger" reconfigure state Changes accepted by WG except for: * Reconfigure-init - punt on multicast reconfigure-init * Spec needs review of options - which are required in base spec? * Spec needs review of error codes Authors will revise spec according to WG input from meeting discussion and based on input from Francis Dupont. - Discussion of outstanding issues * Temporary addresses * IA identification * DHCP-DNS interaction WG will continue to consider thses issues through the WG mailing list. From owner-dhcp-v4@bucknell.edu Wed Apr 4 14:02:55 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27621 for ; Wed, 4 Apr 2001 14:02:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34Huxe02486; Wed, 4 Apr 2001 13:56:59 -0400 (EDT) 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 f34Hure06718; Wed, 4 Apr 2001 13:56:54 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sj-dial-4-44.cisco.com [171.68.181.173]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05977; Wed, 4 Apr 2001 13:56:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20010404133654.031cefb8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Apr 2001 13:38:25 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from 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 Here are my draft minutes from the WG meeting. Please respond with additions, corrections or comments by 5PM, 4/6. - Ralph Summary of DHC WG meetings in Minneapolis. Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes Droms announced that the relay information option, load balancing and authentication specs have been accepted as draft standards. DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt The WG finds this option acceptable in principle; however, the specific format and encoding of data in the option is still an issue. Authors want simple ASCII text encoding of DNS name or dotted decimal IP address; WG recommends RFC1035 encoding for DNS name and binary encoding of IP address with flag to indicate which encoding is in use. WG has selected RFC1035 for other recent options. Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt This spec is ready for WG last call. The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Author will rev spec, changing "MUST implement" to "SHOULD implement"; spec will then we ready for WG last call. Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt This draft enables the CSR option as well as other options that may require more than 255 data bytes. Kim Kinnear will forward spec fixes to author. Next rev of spec will be ready for WG last call. The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt This draft depends on the long DHCP options draft. Bernie Volz will forward spec fixes to author. Next rev of spec will be ready for WG last call. DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt Kinnear will review last call comments and issue concerning addresses in protocol (does NAT affect server-server identification using IP addresses?). Next rev of spec will be ready for WG last call. DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Spec requires further work with input from WG. Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt This spec is ready for WG last call. DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt These specs will be taken on as DHC WG work items. Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Author will work with Droms and Schnizlein to revise draft. Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt This spec will be taken on as a DHC WG work item. ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Report from DDDT (Dynamic DNS Design Team) Bernard Aboba, 15 minutes The DDDT has developed an "Analysis of DNS Server Discovery Mechanisms for IPv6" . One of the discovery mechanisms uses DHCP messages and semantics to pass DNS server information to clients. Aboba presented a summary of the report for the information of the DHC WG. Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt - Review of changes in current draft - Review of design team teleconference Summary of changes: * Added new messages: Confirm, Renew, Rebind, Decline * Uniform format for all client-server messages * Clarified relay agent forwarding * Advertise messages include offered addresses for client selection * Clients multicast all messages to accommodate relay agent options; will add new option to allow server control of use of unicast * New Reconfigure-init semantics - "trigger" reconfigure state Changes accepted by WG except for: * Reconfigure-init - punt on multicast reconfigure-init * Spec needs review of options - which are required in base spec? * Spec needs review of error codes Authors will revise spec according to WG input from meeting discussion and based on input from Francis Dupont. - Discussion of outstanding issues * Temporary addresses * IA identification * DHCP-DNS interaction WG will continue to consider thses issues through the WG mailing list. From owner-dhcp-v4@bucknell.edu Wed Apr 4 16:15:53 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00635 for ; Wed, 4 Apr 2001 16:15:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34K7me25537; Wed, 4 Apr 2001 16:07:48 -0400 (EDT) Received: from schools.hcde.org ([208.183.183.174]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f34K7ie12482 for ; Wed, 4 Apr 2001 16:07:44 -0400 (EDT) Received: by SCHOOLS with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 16:08:03 -0400 Message-ID: From: Cramer Ron To: DHCPv4 discussion list Subject: Help with command line Date: Wed, 4 Apr 2001 16:07:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Cramer_R@hcde.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN We have set up a win2k dhcp server to serve 80 schools here. It is being run on a single server on the wan. I have to add all 80 scopes and wanted to know if there is a command line to do this easy? Or if I have to use the wizard to set these up. Thanks Ronnie Cramer Network Engineer Hamilton County Dept of Education Chattanooga, Tennessee (423)209-5507 From owner-dhcp-v4@bucknell.edu Wed Apr 4 16:19:37 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00771 for ; Wed, 4 Apr 2001 16:19:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34KG4e30586; Wed, 4 Apr 2001 16:16:05 -0400 (EDT) Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f34KFNe12224 for ; Wed, 4 Apr 2001 16:15:24 -0400 (EDT) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 04 Apr 2001 13:13:41 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 4 Apr 2001 13:13:41 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD58552B@mailserver.sylantro.com> From: "Joe Aiello" To: DHCPv4 discussion list Subject: RE: Help with command line Date: Wed, 4 Apr 2001 13:13:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 16D55FFF334922-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Reply-To: Joe.Aiello@sylantro.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Microsoft has a lot on the Win2K server. Here is the link to command line options http://windows.microsoft.com/windows2000/en/server/help/sag_DHCP_pro_Command Node.htm Joe Aiello System Engineer Sylantro Systems http://www.sylantro.com 408-626-3032 -----Original Message----- From: Cramer Ron [mailto:Cramer_R@hcde.org] Sent: Wednesday, April 04, 2001 1:07 PM To: DHCPv4 discussion list Subject: Help with command line We have set up a win2k dhcp server to serve 80 schools here. It is being run on a single server on the wan. I have to add all 80 scopes and wanted to know if there is a command line to do this easy? Or if I have to use the wizard to set these up. Thanks Ronnie Cramer Network Engineer Hamilton County Dept of Education Chattanooga, Tennessee (423)209-5507 From owner-dhcp-v4@bucknell.edu Thu Apr 5 09:22:36 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01219 for ; Thu, 5 Apr 2001 09:22:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f35DDSe06239; Thu, 5 Apr 2001 09:13:28 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f35DDIe01288 for ; Thu, 5 Apr 2001 09:13:19 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 05 Apr 2001 18:50:55 +0530 Received: from radhard (radhard.future.futsoft.com [10.0.12.108]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f35DCoE14616 for ; Thu, 5 Apr 2001 18:42:50 +0530 Received: by localhost with Microsoft MAPI; Thu, 5 Apr 2001 18:37:52 -0300 Message-Id: <01C0BDFF.85FE0060.radhard@future.futsoft.com> From: Radha Rani Reply-To: "radhard@future.futsoft.com" To: DHCPv4 discussion list Subject: test mail Date: Thu, 5 Apr 2001 18:37:51 -0300 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit From owner-dhcp-v4@bucknell.edu Thu Apr 5 09:41:16 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01930 for ; Thu, 5 Apr 2001 09:41:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f35Dche12061; Thu, 5 Apr 2001 09:38:43 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f35Dcce04380 for ; Thu, 5 Apr 2001 09:38:38 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 05 Apr 2001 19:16:17 +0530 Received: from radhard (radhard.future.futsoft.com [10.0.12.108]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f35DcBE15768 for ; Thu, 5 Apr 2001 19:08:11 +0530 Received: by localhost with Microsoft MAPI; Thu, 5 Apr 2001 19:03:11 -0300 Message-Id: <01C0BE03.0F5CE760.radhard@future.futsoft.com> From: Radha Rani Reply-To: "radhard@future.futsoft.com" To: DHCPv4 discussion list Subject: DHCP Relay Agent Option Date: Thu, 5 Apr 2001 19:03:10 -0300 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, Please clarify the following doubt in DHCP relay agent option rfc (RFC 3046). In Section 2.1 of the RFC3046 it is mentioned that overall adding of the relay agent option is configurable. Is this configuration per-interface or for all users of relay agent. Thanks in advance. Regards, Radha. From owner-dhcp-v4@bucknell.edu Mon Apr 9 06:57:00 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02694 for ; Mon, 9 Apr 2001 06:57:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f39Anhe27638; Mon, 9 Apr 2001 06:49:43 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f39Anae16150 for ; Mon, 9 Apr 2001 06:49:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02418; Mon, 9 Apr 2001 06:49:34 -0400 (EDT) Message-Id: <200104091049.GAA02418@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-03.txt Date: Mon, 09 Apr 2001 06:49:34 -0400 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 reconfigure extension Author(s) : P. De Schrijver, Y. T'Joens, C. Hublet Filename : draft-ietf-dhc-pv4-reconfigure-03.txt Pages : 5 Date : 06-Apr-01 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-pv4-reconfigure-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010406124938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010406124938.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Apr 9 16:34:54 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16247 for ; Mon, 9 Apr 2001 16:34:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f39KPle17507; Mon, 9 Apr 2001 16:25:47 -0400 (EDT) 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 f39KOIe04970 for ; Mon, 9 Apr 2001 16:24:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-129.cisco.com [161.44.149.129]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08218 for ; Mon, 9 Apr 2001 16:23:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20010409162223.00b1b500@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Apr 2001 16:23:31 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Presentations from DHC WG meeting 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 If you used an electronic presentation during the DHC WG meeting in Minneapolis, please send me a copy for inclusion in the minutes (if you haven't already done so). Thanks... - Ralph From owner-dhcp-v4@bucknell.edu Tue Apr 10 21:49:36 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01027 for ; Tue, 10 Apr 2001 21:49:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3B1g0e22827; Tue, 10 Apr 2001 21:42:01 -0400 (EDT) Received: from qmail.jsust.edu.cn (qmail.jsust.edu.cn [202.195.160.171]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3B1fne14674 for ; Tue, 10 Apr 2001 21:41:50 -0400 (EDT) Received: (qmail 494 invoked from network); 11 Apr 2001 01:45:35 -0000 Received: from unknown (HELO justant) ([202.195.160.188]) (envelope-sender ) by qmail.jsust.edu.cn (qmail-ldap-1.03) with SMTP for ; 11 Apr 2001 01:45:35 -0000 Date: Wed, 11 Apr 2001 09:41:21 +0800 From: James Power X-Mailer: The Bat! (v1.51) Business Reply-To: jamespower@263.net X-Priority: 3 (Normal) Message-ID: <114014372.20010411094121@263.net> To: DHCPv4 discussion list Subject: Where can I find the newest DHCP Schema for LDAP (ietf draft)? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, Please forgive my bother if there's an obvious answer for this question. I'm considering implement a simple LDAP-based DHCP server and I have been looking for an existing LDAP schema for reference. Yesterday I found a dead link pointing to a "DHCP server LDAP schema" at dhcp.org, now I wonder what's going on with that schema? Where or when can I find the newest DHCP Schema for LDAP? Thanks a lot. - Regards, James From owner-dhcp-v4@bucknell.edu Wed Apr 11 07:07:13 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20292 for ; Wed, 11 Apr 2001 07:07:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3BB1Te26620; Wed, 11 Apr 2001 07:01:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3BB1Ne02925 for ; Wed, 11 Apr 2001 07:01:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20041; Wed, 11 Apr 2001 07:01:21 -0400 (EDT) Message-Id: <200104111101.HAA20041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-04.txt Date: Wed, 11 Apr 2001 07:01:20 -0400 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 reconfigure extension Author(s) : P. De Schrijver, Y. T'Joens, C. Hublet Filename : draft-ietf-dhc-pv4-reconfigure-04.txt Pages : 5 Date : 10-Apr-01 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-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-dhc-pv4-reconfigure-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-dhc-pv4-reconfigure-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 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: <20010410135006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010410135006.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Apr 12 07:02:24 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25860 for ; Thu, 12 Apr 2001 07:02:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3CAufe12565; Thu, 12 Apr 2001 06:56:41 -0400 (EDT) Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3CAuYe10154 for ; Thu, 12 Apr 2001 06:56:34 -0400 (EDT) To: DHCPv4 discussion list From: duanpengbo@mail.zte.com.cn Date: Thu, 12 Apr 2001 18:50:11 +0800 Message-ID: X-MIMETrack: Serialize by Router on notes_svr7/zte_ltd(Release 5.0.4 |June 8, 2000) at 2001-04-12 06:56:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply-To: duanpengbo@mail.zte.com.cn Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, Who can tell me where to get the document "draft-ietf-dhc-aaa-requirements-00.txt"? From owner-dhcp-v4@bucknell.edu Thu Apr 12 08:26:08 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27847 for ; Thu, 12 Apr 2001 08:26:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3CCIte32651; Thu, 12 Apr 2001 08:18:55 -0400 (EDT) Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3CCIge19874 for ; Thu, 12 Apr 2001 08:18:43 -0400 (EDT) Subject: Authentication-enabled DHCP Client To: DHCPv4 discussion list From: Yang.Jinping@mail.zte.com.cn Date: Thu, 12 Apr 2001 20:12:21 +0800 Message-ID: X-MIMETrack: Serialize by Router on notes_svr7/zte_ltd(Release 5.0.4 |June 8, 2000) at 2001-04-12 08:19:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply-To: Yang.Jinping@mail.zte.com.cn Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, It seems to be a trend to utilize the combination of DHCP-AUTH and RADIUS to offer PPP dial-in style Ethernet Access. In my opinion, the dominating reason to do so is for the sake of multicasting. My question is, is the authentication process essentially the same as the CHAP+RADIUS in PPP dial-in mode? as far as I know, Windows don't support such authentication features. So I am wondering whether there is any DHCP client software, commercial or free, which has implemented authentication-enabled DHCP. Mr. Bmukherj ever said here that they have had a prototype implementation. Would you please say more details about your accomplishment, or tell me how to explore by myself? Thanks in advance for any enlightenment. From owner-dhcp-v4@bucknell.edu Mon Apr 16 09:59:07 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03766 for ; Mon, 16 Apr 2001 09:59:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3GDlGe08374; Mon, 16 Apr 2001 09:47:16 -0400 (EDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3GDjpe06656 for ; Mon, 16 Apr 2001 09:45:51 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 16 Apr 2001 09:43:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 09:43:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C15E073@zcard031.ca.nortel.com> From: "Biswaroop Mukherjee" To: DHCPv4 discussion list Subject: FW: request for reference 'draft-ietf-dhc-aaa-requirements-00.tx t','draft-ietf-dhc-enhance-requirements-00.txt' Date: Mon, 16 Apr 2001 09:43:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C67B.3923F9F0" 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_000_01C0C67B.3923F9F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C67B.3923F9F0" ------_=_NextPart_001_01C0C67B.3923F9F0 Content-Type: text/plain Some people in the list had requested the references. Please find copies of them from our archives attached here, for information only. Note however that all the restrictions on the use of expired IETF drafts apply. -- Roop > -----Original Message----- > From: Gage, Bill [WDLN2:AN00-M:EXCH] > Sent: Thursday, April 12, 2001 8:26 AM > To: 'tian.hongliang@mail.zte.com.cn' > Cc: Mukherjee, Biswaroop [WDLN2:AN33:EXCH] > Subject: RE: request for reference > 'draft-ietf-dhc-aaa-requirements-00.txt','draft-ietf-dhc-enhance-requireme > nts-00.txt' > > Please find attached the documents you requested. > > > Cheers ... > > > > <> > <> ------_=_NextPart_001_01C0C67B.3923F9F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: request for reference = 'draft-ietf-dhc-aaa-requirements-00.txt','draft-ietf-dhc-enhance-require= ments-00.txt'

Some people in the list had = requested the references. Please find copies of them from our archives = attached here, for information only. Note however  that all the = restrictions on the use of expired IETF drafts apply.

        -- Roop

-----Original Message-----
From:   Gage, Bill [WDLN2:AN00-M:EXCH]
Sent:   Thursday, April 12, 2001 8:26 AM
To:     'tian.hongliang@mail.zte.com.cn'
Cc:     Mukherjee, Biswaroop [WDLN2:AN33:EXCH]
Subject:       = RE: request for reference  = 'draft-ietf-dhc-aaa-requirements-00.txt','draft-ietf-dhc-enhance-require= ments-00.txt'

Please find attached the documents you = requested.


Cheers ...



= <<draft-ietf-dhc-aaa-requirements-00.txt>> = <<draft-ietf-dhc-enhance-requirements-00.txt>>

------_=_NextPart_001_01C0C67B.3923F9F0-- ------_=_NextPart_000_01C0C67B.3923F9F0 Content-Type: text/plain; name="draft-ietf-dhc-aaa-requirements-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-dhc-aaa-requirements-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Subir = Das INTERNET-DRAFT Anthony = McAuley Internet Engineering Task Force Telcordia = Technologies draft-ietf-dhc-aaa-requirements-00.txt Shinichi = Baba Date: March 8, 2000 Yasuro = Shobatake Expires: August, 2000 Toshiba America Research = Inc. Authentication, Authorization, and Accounting Requirements for=20 Roaming Nodes using DHCP =20 Status of this memo=20 This document is an Internet-Draft and is in full conformance with=20 all provisions of sections 10 of RFC 2026. =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as=20 "work in progress". =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html. Abstract The AAA working group is currently defining the requirements for=20 Authentication, Authorization, and Accounting (AAA). This draft lists the AAA requirements to aid roaming nodes using a dynamic=20 address configuration protocol such as DHCP. The node may or may=20 not be using Mobile IP [3] (with co-located care-of-address) or = other dynamic address binding protocol. ITSUMO Group Expires August 2000 [Page 1] =0C Internet Draft AAA Requirements using DHCP March = 2000 1. Introduction A network providing communication services to nodes from foreign=20 domains, must use Authorization, Authentication, and Accounting = (AAA) services [1,2]. A dynamically roaming node places stronger=20 requirements on AAA than a static node. Moreover, next generation=20 network applications will raise the requirements on IP network even higher. The Mobile IP [3] Working Group is currently specifying the=20 requirements for a roaming node using Mobile IP with Foreign Agents=20 [4]. This document specifies the requirements for a roaming node who obtains an address using DHCP [5] [17] or similar node configuration = protocol (e.g., DRCP [6]).=20 Recent drafts [7,8] specify how to add authentication to DHCP=20 messages. This allows clients to verify DHCP servers or servers to=20 verify DHCP clients. It does not, however, specify the interaction=20 with a AAA protocol to allow roaming users to access networks in=20 multiple administrative domains. The document is independent of whether the roaming node uses dynamic address binding. The roaming node getting an address through DHCP = [5] and once authenticated via AAA [1, 13,14] may also use Mobile IP = with co-located addresses, dynamic DNS updates [9,10], or any other=20 dynamic address binding techniques [15,16]. The document does not=20 discuss the pros and cons of how best to support roaming users, only to ensure that the AAA protocol is sufficiently flexible to support=20 both nodes using Mobile IP with Foreign Agents and nodes using DHCP=20 (with or without Mobile IP).=20 Since many of the requirements for DHCP are similar to those for Mobile IP with Foreign Agents, we borrow heavily from the Mobile IP=20 requirements document [3, 4]. 1.1 Requirements Terminology=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ]. ITSUMO Group Expires August 2000 [Page 2] =0C Internet Draft AAA Requirements using DHCP March = 2000 =20 2. Basic Model Figure 2 shows that our general model is very much similar to that=20 described in [4]. The only change is that we do not assume the AAA=20 authentication is necessarily done in a home domain. We assume, more = generally, that the roaming node authentication is done in a=20 (possibly distributed) Public AAA (AAAP), which is similar to AAA=20 broker model. The reasons for using the AAAP are discussed in = section 4. Each DHCP client might use a different AAAP that can check its=20 credentials, or they may share the same AAAP (even if they are from=20 different domains). =20 Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | =20 | | | +--------+ | +---+---+ | | DHCP | DHCP | | DHCP | | =20 | Client |-------|--| Server| |=20 +--------+ | +-------+ | AAAP =3D Public = authority | | AAAL =3D local authority +-------------+ Figure 1: AAA Servers Model DHCP server does not have direct access to the data needed for=20 authentication. So it is expected that the server will consult the local authority (AAAL) for verification. Since the server and the=20 local authority are in the same domain it is assumed that they will have strong security associations. Alternatively, they may be=20 co-located. On the other hand, AAAL itself may not have enough=20 information stored locally to complete the transaction. However,=20 AAAL is expected to be configured with enough information to=20 negotiate the client's verification with corresponding AAAP.=20 Sometimes client may notify its own AAAP for verification via its=20 registration message (e.g., Client's NAI [11]). The local AAA and=20 public AAA should have sufficient security relationships and access = control so that they can negotiate the authorization and enable the client to have the requested resources. Once this is over, DHCP=20 ITSUMO Group Expires August 2000 [Page 3] =0C Internet Draft AAA Requirements using DHCP March = 2000 server will be notified about the successful negotiation and the=20 server can provide the requested resources to the client. If it is=20 not authorized, server will be informed to terminate the service to the client.=20 3. Requirements =20 Based on the above scenarios, the following specific requirements=20 for AAA can be ascertained. - Either the DHCP Server and AAAL are co-located or they share a=20 security relationship. =20 - The DHCP server should be configured to obtain authorization = from a trusted local AAA server (AAAL). =20 - The local authority (AAAL) has to share, or dynamically establish, security relationships with public authorities (AAAP) that are able to check client credentials.=20 =20 - The client must have a security association with its public=20 authority (AAAP).=20 =20 - Nobody can reconstruct and reuse the credentials that the client uses. =20 - The DHCP server MUST be able to terminate service to the=20 client based on policy determination by the AAA server. =20 - The DHCP server should be able to handle requests for many=20 clients simultaneously.=20 =20 - The client may resend a request if it does not get a reply in some time, so the AAA entities must be designed to operate=20 correctly and efficiently with multiple requests for the same=20 client. =20 - The DHCP server has to keep state for pending client requests=20 while the local authority contacts the appropriate external=20 authority. = =20 - Support replay protection and optional non-repudiation capabilities for all authorization and accounting messages.=20 =20 - AAA server need not know any IP address of the client and it identifies clients by other means, e.g., Network Access =20 ITSUMO Group Expires August 2000 [Page 4] =0C Internet Draft AAA Requirements using DHCP March = 2000 Identifier (NAI). =20 - Client NAI domain allows AAAL to easily determine the AAAP. =20 - The local AAA server MUST support anonymous access. =20 - There is no requirement for AAA to transport `DHCP or other=20 node configuration messages'. =20 - AAA must complete in one round trip. A major component of the =20 setup latency is the time taken to traverse the wide-area=20 Internet that is likely to separate the AAAL and the AAAP.=20 - AAA must allow a node to register once in its domain and move among subnets in the same domain without requiring more AAA. After the initial registration, the AAAP and AAAL would not be needed. =20 - Support accounting information via AAAP servers providing=20 accounting clearinghouse and reconciliation between serving and home networks.=20 =20 - AAA MUST support message privacy and integrity. =20 4. Reasons for using Public AAA AAA servers model in [4] shows a configuration in which the local and the home authority have to share trust. This configuration causes a quadratic growth in the number of trust relationships as the number of AAA authorities (local AAA and home AAA) increases.=20 This has been identified as a problem by the roamops working group=20 [12], and any AAA proposal MUST solve this problem. Using public AAA = (AAAP) solves many of the scalability problems associated with=20 requiring direct business/roaming relationships between every two=20 administrative domains. A public AAA may play the role of a proxy between two administrative domains which have security associations=20 with the AAAP, and relay AAA messages back and forth securely. The AAAP enables the local and home domains to cooperate without requiring each of the networks to have a direct business or security relationship with all the other networks. Thus, AAAPs offer the needed scalability for managing trust relationships between = otherwise independent network domains. Use of the AAAP does not preclude managing separate trust relationships between domains, but it does offer an alternative suitable for commercial environments.=20 ITSUMO Group Expires August 2000 [Page 5] =0C Internet Draft AAA Requirements using DHCP March = 2000 =20 5. Security Considerations =20 This draft defines the AAA requirements for roaming nodes using=20 DHCP or similar type of node configuration protocol. Since AAA is=20 security driven, most of this documents addresses the security=20 considerations AAA must make on behalf of roaming nodes using node=20 configuration protocols.=20 6. Acknowledgements The requirements in section 3 were taken from a draft submitted by=20 S. Glass, S. Jacobs, and C. Perkins of the Mobile IP working group.=20 We would like to acknowledge their work.=20 The authors acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari,=20 S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and=20 Toshiba America Research Incorporated (T. Kodama). References [1] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA=20 Authorizatiopn Requirements," , October 1999. =20 [2] J. Arkko, "Requirements for Internet-scale Accounting=20 Management," , August, 1998. [3] C. Perkins, "IP Mobility Support," RFC 2002, October 1996. [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,=20 Authorization, and Accounting Requirements,"=20 , October, 1999. [5] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131, March, 1997. =20 [6] A. McAuley, S. Das, S. Baba, Y. Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)," ,=20 October, 1999. =20 ITSUMO Group Expires August 2000 [Page 6] =0C Internet Draft AAA Requirements using DHCP March = 2000 =20 [7] R. Droms, "Authentication for DHCP Messages," , October, 1999. =20 [8] V. Gupta, "Flexible Authentication for DHCP Messages,"=20 , October, 1998. [9] A. Gustafsson, "A DNS RR for encoding DHCP information," , October, 1999. =20 [10] M. Stapp, Y. Rekhter, "Interaction between DHCP and DNS," , October, 1999. [11] B. Aboba and M. A. Beadles, "The network access identifier," RFC 2486, January 1999. [12] B. Adoba and G. Zorn, "Criteria for evaluating roaming =20 protocols," RFC 2477, December 1998. =20 [13] J. Wang and R. Wang, "Cellular network Authentication, Authorization, and Accounting requirements," , October, 1999. =20 [14] M. Beadles and et.al., "Criteria for evaluating AAA protocols=20 for network access", , October 1999. [15] H. Schulzrinne and et. al., "SIP: Session initiation protocol," RFC 2543, March 1999. =20 [16] E. Wedlund and H. Schulzrinne, "Mobility support using SIP",=20 Proc. The second ACM International workshop on Wireless Mobile=20 Multimedia, ACM/IEEE, pp 76-82, August, 1999. [17] A. McAuley, S. Das, S. Baba, Y. Shobatake, " Requirements for=20 Extending DHCP into New Environments,"=20 , March, 2000. =20 7. Authors' Addresses Subir Das MCC 1D210R, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com ITSUMO Group Expires August 2000 [Page 7] =0C Internet Draft AAA Requirements using DHCP March = 2000 Anthony J. McAuley =20 MCC 1C235B, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4698 email: mcauley@research.telcordia.com Shinichi Baba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 4759=20 email: sbaba@tari.toshiba.com =20 Yasuro Shobatake Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 3951 email: yasuro.shobatake@toshiba.co.jp ITSUMO Group Expires August 2000 [Page 8] ------_=_NextPart_000_01C0C67B.3923F9F0 Content-Type: text/plain; name="draft-ietf-dhc-enhance-requirements-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-dhc-enhance-requirements-00.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= Network Working Group Anthony = McAuley=0A= INTERNET-DRAFT Subir = Das=0A= Internet Engineering Task Force Telcordia = Technologies=0A= draft-ietf-dhc-enhance-requirements-00.txt Shinichi = Baba=0A= Date: March 8, 2000 Yasuro = Shobatake=0A= Expires: August, 2000 Toshiba America Research = Inc.=0A= =0A= =0A= =0A= Requirements for Extending DHCP into New Environments=0A= =0A= =0A= =0A= Status of this memo =0A= =0A= This document is an Internet-Draft and is in full conformance with = =0A= all provisions of sections 10 of RFC 2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering = =0A= Task Force (IETF), its areas, and its working groups. Note that =0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six =0A= months and may be updated, replaced, or obsoleted by other =0A= documents at any time. It is inappropriate to use Internet-=0A= Drafts as reference material or to cite them other than as =0A= "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at =0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= =0A= Abstract=0A= =0A= The Dynamic Host Configuration Protocol (DHCP) provides a widely =0A= deployed framework for host registration and configuration [DHC]. = =0A= DHCP, however, was designed only for fixed hosts on physically = secure=0A= LANs. Other protocols fill some of the gap. PPP [PPP] is a good =0A= solution for many commercial service providers (where framing is =0A= needed). Mobile IP [MIP] is ideal for registering and configuring=0A= roaming users (when transparent address binding is needed). This =0A= still leaves many environments where there is no ideal solution,=0A= such as: roaming users who do not need transparent address = binding=0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 1]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= (e.g., a mobile web browser), and commercial service providers =0A= who want to support home networking with multiple nodes. This = draft=0A= proposes DHCP as the best protocol to meet these new needs, because = =0A= it leave open how (and whether) to provide other functions, such as = =0A= framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode), = =0A= inter-domain AAA (e.g., [AAAR]), or address distribution (e.g., =0A= [DAAP]). We describe and solicit feedback on seven new requirements = =0A= that would be placed on DHCP to meet these needs. =0A= =0A= =0A= =0A= 1. Introduction=0A= =0A= Most future networks will use IP technology. To provide = heterogeneity=0A= and flexibility, devices will likely access this IP-based network = by=0A= directly sending IP packets. In such an environment it is natural = to=0A= consider using IP-based protocols for user-network signaling, since = =0A= they can be used across any wired or wireless access network.=0A= =0A= =0A= 1.1 Architecture=0A= =0A= Figure 1 shows a high level functional architecture of a future = IP-=0A= based network, with both a fixed and a roaming clients attaching=0A= to various wired or wireless Access Networks. We assume the client = =0A= has at least one physical interface onto the access network, but =0A= can also have other physical and virtual interfaces. The access =0A= network, which may contain multiple Layer 2 nodes (such as hubs), = =0A= connects to at least one Edge Router and Edge Agent (that may be=0A= co-located). The Regional Backbone connects all the Edge Routers = in=0A= an administrative domain and the Global Internet interconnects all = =0A= the regional networks.=0A= =0A= We assume the network may need to change client configuration of = even=0A= fixed nodes at any time, but that typically clients keep the same = =0A= configuration (e.g., IP address) while they are within a given = access=0A= network. Micro mobility within the access network is handled at = Layer=0A= 2. Depending on how routing is done, the client may or may not need = a=0A= new configuration when it moves to a new access network within the = =0A= same domain (macro mobility) [CEL] [HAW]. We assume, however, that = =0A= clients must be reconfigured when moving to a new domain (global =0A= mobility).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 2]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= . <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> = .=0A= . +---------+ . +--------------+ . +---------+ = .=0A= . | Domain | . | Inter-domain | . | Domain | = .=0A= . | Agent | . | Agent | . | Agent | = .=0A= . +---------+ . +--------------+ . +---------+ = .=0A= . | . | . | = .=0A= . __|__ . __|___ . __|__ = .=0A= . / \ . / \ . / \ = .=0A= . / \ . / \ . / \ = .=0A= . / Regional\________/ Global \_________/ Regional\ = .=0A= . \ Backbone/ . \ Internet / . \ Backbone/ = .=0A= . ____\ /____ . \ / . ____\ /____ = .=0A= . / \_____/ \ . \______/ . / \_____/ \ = .=0A= . / | \ . . / | \ = .=0A= . / | \ . . / | \ = .=0A= . +--------+ . . +--------+ = .=0A= . .. | Edge | .. . . .. | Edge | .. = .=0A= . | Router | . . | Router | = .=0A= . +--------+ . . +--------+ = .=0A= . .. | | .. . . .. | | .. = .=0A= . +--------+ | | +--------+ . . +--------+ | | +--------+ = .=0A= . | Edge | | | | Edge | . . | Edge | | | | Edge | = .=0A= . | Agent | | | | Agent | . . | Agent | | | | Agent | = .=0A= . +--------+ | | +--------+ . . +--------+ | | +--------+ = .=0A= . | | | | . . | | | | = .=0A= . | _____ | | _____ | . . | _____ | | _____ | = .=0A= . |/ \__| |__/ \| . . |/ \__| |__/ \| = .=0A= . / \ / \ . . / \ / \ = .=0A= . / Access \ .. / Access \ . . / Access \ .. / Access \ = .=0A= . \ Network / \ Network / . . \ Network / \ Network / = .=0A= . \ / \ / . . \ / \ / = .=0A= . \_____/ \_____/ . . \_____/ \_____/ = .=0A= . | | . . | | = .=0A= | | | |=0A= +---------+ +---------+ global macro =0A= | Fixed | | Mobile | ****************> *************> = =0A= | Client | | Client | mobility mobility =0A= +---------+ +---------+ =0A= =0A= =0A= Figure 1: Functional Network Architecture =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 3]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= Figure 1 is meant to be very general functional diagram. It does = not,=0A= for example, specify where a Base Station (BS) is located. BSs = could=0A= be within the access networks (Layer 2 BS) or in the Edge Router (IP = =0A= BS). The Domain and Inter-Domain agents which perform functions such = =0A= as registration and AAA, are shown as single boxes; but both could = be=0A= implemented as multiple nodes (possibly in a hierarchical = structure).=0A= =0A= =0A= 1.2 Functional Scope=0A= =0A= The functions needed to support users' accessing IP-based networks = =0A= vary, depending on network, user, and application characteristics. = =0A= Some basic functions include:=0A= o Registration: Users indicate their presence and their requirements= =0A= to a network (e.g., give a user name [NAI]). =0A= o Configuration: Networks adapt nodes to the particular network =0A= characteristics (e.g., give an IP address).=0A= o Framing: Indicates the start and end of packets in a data = stream.=0A= o Compression: Compress RTP/UDP/TCP/IP header and data over an =0A= access network.=0A= o Dynamic Address Binding: Allows corresponding nodes to locate =0A= users and allows continuous communication as the user moves = among=0A= networks.=0A= =0A= This draft is concerned only with the first two functions, which = we=0A= believe have a natural association (see Section 3.5). This draft =0A= considers only server based methods for registration and =0A= configuration within a single IP domain. The network servers are =0A= themselves configured with information such as an IP address pool; = =0A= but, server configuration is beyond the scope of this draft. We =0A= assume each access network has at least one edge server (possibly = =0A= co-located with the edge router), though it could be as simple as a = =0A= relay agent.=0A= =0A= =0A= 1.3 Requirements Terminology =0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=0A= "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in = this=0A= document are to be interpreted as described in RFC 2119 [REQ].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 4]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 1.4 Terminology=0A= =0A= This document uses the following terms:=0A= =0A= o "AAA"=0A= Authentication, authorization and accounting=0A= =0A= o "BOOTP"=0A= The Bootstrap Protocol (BOOTP) [BOO1] [BOO2].=0A= =0A= o "DHCP"=0A= The Dynamic Host Configuration Protocol (DHCP) used to = configure=0A= Internet hosts.=0A= =0A= o "DHCP client"=0A= A DHCP client is an Internet host using DHCP to obtain=0A= configuration parameters such as a network address.=0A= =0A= o "DHCP relay agent"=0A= A relay agent is an Internet host that passes DHCP messages=0A= between DHCP clients and DHCP servers.=0A= =0A= o "DHCP server"=0A= A DHCP server is an Internet node that returns configuration=0A= parameters to DHCP clients.=0A= =0A= o "Domain Agent"=0A= An Internet node that provides a centralized service within a=0A= domain (e.g., DHCP server)=0A= =0A= o "Edge Router"=0A= An IP router connecting an IP subnet to other networks.=0A= =0A= o "Edge Agnet"=0A= An IP node (host or router) that is connected to an IP subnet = and=0A= provides services (e.g., DHCP relay agent).=0A= =0A= o "Inter-domain Agent"=0A= An Internet node that provides services for a node anywhere in = the=0A= Internet. =0A= =0A= o "NAI"=0A= Network Access Identifier of the form user@domain [NAI].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 5]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 2 Registration and Configuration Protocols=0A= =0A= There are several TCP/IP protocol choices for performing = registration=0A= and configuration:=0A= o The Point-to-Point Protocol (PPP).=0A= o The Mobile IP protocol (MIP). =0A= o The Dynamic Host Configuration Protocol (DHCP).=0A= =0A= =0A= 2.1 PPP=0A= =0A= Although its primary function is packet framing, PPP also = provides=0A= well tested and widely deployed registration and configuration =0A= capabilities. PPP [PPP] clients sends registration information, = such=0A= as login and password to an access concentrator on the Layer 2 =0A= network to which the client is connected. The access concentrator = can=0A= then either directly configure the client or use the Layer 2=0A= Tunneling Protocol [PPPL] to tunnel PPP packets to and from a = server=0A= anywhere in the Internet. The powerful PPP registration and =0A= configuration capabilities are now even used when framing is not =0A= needed (e.g., PPPoE [PPPE]). The only cost is that it leaves some = of=0A= the PPP framing overhead (2 bytes for framing, 2 bytes for CRC, up = to=0A= 4 other bytes, and bit or byte stuffing overhead). =0A= =0A= =0A= 2.2 Mobile IP=0A= =0A= Although its primary function is providing location service and =0A= continuous connectivity to roaming users, Mobile IP [MIP] [MIP6] = also=0A= provides a flexible registration and configuration capabilities. = The=0A= Mobile IP client sends registration information to a Foreign Agent = =0A= [MIPA] [MIPC] [MIPD] [MIPN] [MIPS] [MIPT] on the Layer 2 network to = =0A= which the client is connected. The Foreign Agent can then configure = =0A= the client, after getting authorization from the user's Home Agent. = =0A= The registration and configuration capabilities could be provided = by=0A= Mobile IP for all roaming users, even when transparent binding is = not=0A= needed (e.g., for web browsing) or may need alternative mechanisms = =0A= (viz., SIP for real-time applications [SIP] [SIPM]). The only costs = =0A= are: a) triangular routing, b) having to configure a permanent home = =0A= address, and c) depending on a home network.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 6]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 2.3 DHCP=0A= =0A= DHCP provides a well tested and widely deployed framework for = passing=0A= configuration information to hosts [DHC]. A DHCP client in a host=0A= broadcasts a DISCOVER control message to the access network. A=0A= server picks up the message and either a) returns an OFFER = message=0A= (server) or b) relays the message to a central DHCP server. DHCP is = =0A= unique in that it:=0A= o Has no additional functions (e.g., framing or address = binding).=0A= o Requires no client preconfiguration (e.g., for home = addresses).=0A= o No overhead to data traffic (out-of-band signaling).=0A= o Allows nodes to go on and off without re-registration. =0A= o Allows a single network server per domain (using relay = agents).=0A= =0A= DHCP is likely to continue to gain in popularity with recent =0A= enhancements, such as Server fail-over [DHCF], Load balancing = [DHCB],=0A= Dynamic updating of DNS [DHCD], LDAP database management [DHCL], and = =0A= Authentication [DHCA]. =0A= =0A= =0A= 2.4 Choice=0A= =0A= PPP, Mobile IP and DHCP were designed for different environments.=0A= Thus, network designers select the registration and configuration = =0A= protocol that best fits the types of access network and likely = client=0A= applications. For example, networks using phone lines for access = will=0A= typically use PPP; wireless providers supporting roaming TCP =0A= application, such as telnet and ftp, will use Mobile IP; and =0A= corporate networks will use DHCP. =0A= =0A= The open question is what registration and configuration protocol = =0A= will be used in environments that do not fit into the PPP, Mobile = IP,=0A= or DHCP assumptions? Examples of these environments are:=0A= o Commercial service providers who want to support flexible home = =0A= networking.=0A= o Roaming users who either do not need transparent binding (e.g., = =0A= just web browsing) or prefer alternative mechanisms (e.g., SIP = for=0A= real-time applications).=0A= PPP, Mobile IP and DHCP could all be adapted to better some or all = of=0A= these environments. This draft proposes DHCP as the best protocol = to=0A= meet these new needs, because it leave open how (and whether) to =0A= provide other functions, such as framing (e.g., PPP), locating = (e.g.,=0A= Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or = =0A= address distribution (e.g., [DAAP]). We describe the new = requirements =0A= that would be placed on DHCP in the next Section.=0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 7]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 3. Requirements for Extending DHCP into New Environments=0A= =0A= Though DHCP has many desirable features, the following requirements = =0A= created by new environments are not fully met by DHCP:=0A= o R1 Rapid client configuration (milliseconds rather than = seconds).=0A= o R2 Rapid client reconfiguration (independent of lease time).=0A= o R3 Efficient use of scarce wireless bandwidth. =0A= o R4 Allowing clients to be routers.=0A= o R5 Enhanced registration (e.g, user identification and = security).=0A= o R6 Flexible proxies that can act as both relay or server. =0A= o R7 Allowing dynamic server and relay reconfiguration.=0A= This section gives a brief description and motivation for each new = =0A= requirement.=0A= =0A= =0A= 3.1 Rapid configuration=0A= =0A= Configuration latency is critical to users roaming among wireless = =0A= networks. A DHCP client accepts an OFFER by returning a REQUEST =0A= message to the server (which the server ACKS). The client, = however,=0A= only configures its new address after checking that no other node = on=0A= the subnet is using it. The DHCP specification [DHC] says a client = =0A= SHOULD do ARP checking before an assigned address is used. This =0A= "in-line" checking results in long delay (typically 3-15 seconds) = =0A= before communication can resume after a move; too long for many=0A= roaming users. While duplicate detection is desirable, it need not = be=0A= part of the critical path. One possible alternative, for example, = =0A= would be to have the server do ARP checking on addresses before they = =0A= are requested. =0A= =0A= The goal is to get configuration in milliseconds (bounded mostly = by=0A= by the speed of the access link) rather than seconds.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 8]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 3.2 Rapid reconfiguration=0A= =0A= A recent draft [DHCR] has proposed a new DHCP FORCERENEW message =0A= that allows servers to force clients to immediately reconfigure.=0A= To enable rapid reconfiguration (e.g., when a roaming user moves = into=0A= a new subnet or topology changes), clients must rapidly detect the = =0A= server request. Today, DHCP clients typically go into sleep mode, = =0A= not listening to DHCP messages until the lease is due for renewal. = =0A= Clients can use external triggers, such as a layer 2 hand-off =0A= indication or an SNMP V3 request message, to jump DHCP into a new = =0A= state. These triggers, however, may not always: a) be available, = =0A= b) be standardized, c) have enough information. The information may = =0A= help client to decide if it is in a new subnet or to get the = location=0A= of a DHCP server (to prevent having to broadcast). =0A= =0A= The goal is to be able to rapidly reconfigure DHCP clients, at any = =0A= time, without relying on external triggers.=0A= =0A= =0A= 3.3 Bandwidth Efficiency=0A= =0A= DHCP message overhead is considerably larger than needed, mainly =0A= because DHCP kept the same syntax as BOOTP [BOO1] [BOO2] [BOOD]. = This=0A= was not a problem in the old paradigm where hosts connect to DHCP = =0A= servers over high speed LANs; especially since DHCP overhead mainly = =0A= occurs when a host first boots and DHCP adds nothing to normal = packet=0A= communication overhead. The overhead is perhaps only a problem for = =0A= roaming nodes using some wireless access networks. Depending on the = =0A= size of the IP subnets, roaming users might need to reconfigure as = =0A= fast as every few seconds. Depending on the speed and error rate of = =0A= the wireless access networks, reducing DHCP message size could =0A= significantly improve bandwidth efficiency. (The error rate can be = =0A= important since larger messages result in higher probability of = loss,=0A= that increases latency and bandwidth needs.)=0A= =0A= The goal is to minimize DHCP message size, by reducing the size = of=0A= individual DHCP messages and possibly by reducing the total number = of=0A= messages.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 9]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 3.4 Clients as Routers=0A= =0A= DHCP specification [DHC] says clients must be hosts and that it "is = =0A= not intended for use in configuring routers." This was not a problem = =0A= in the old paradigm, where routers were typically part of a =0A= hierarchical network that could be manually configured by a = system's=0A= administrator. As the size and complexity of networks increase=0A= (e.g., with more small devices with low power wireless interfaces), = =0A= routing functionality becomes desirable in places where manual=0A= configuration is not desirable. We are NOT proposing that DHCP be=0A= extended to simultaneously configure multiple router interfaces = or=0A= to distribute address pools; only that DHCP could configure a = single=0A= router interface over a subnet where there is a DHCP server (or=0A= relay). This would require no change in DHCP functionality; only a = =0A= change in allowable application.=0A= =0A= The goal is to allow DHCP to configure hosts and routers. =0A= =0A= =0A= 3.5 Enhanced Registration=0A= =0A= Commercial service providers need a scalable way to identify and =0A= authenticate users. In addition they may need other registration =0A= information such as: a) the location of the client's AAA server =0A= (for inter-domain authentication [DHCZ], b) negotiate service =0A= requirements and costs, and c) trigger other services (possibly=0A= based on a user profile). Many of these features are now being=0A= defined for DHCP, but filling the missing needs would be helpful. = =0A= We assume that DHCP itself only deals with intra-domain = registration;=0A= a separate AAA protocol [AAAD] [AAAR] meets the inter-domain =0A= requirements.=0A= =0A= The registration and configuration could be done in separate =0A= protocols; however we believe integrating the two functions is=0A= desirable. First, it reduces the latency, since it requires only=0A= one round trip from the client to the network. Second, it forces=0A= users to register before they can be configured. Clearly, devious=0A= users could still configure themselves, but now they cannot use =0A= DHCP to do this.=0A= =0A= The goal is to allow DHCP to meet the registration needs of = diverse=0A= service providers.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 10]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 3.6 DHCP Proxies=0A= =0A= A DHCP client must either connect to a node acting as a DHCP server = =0A= or connect to a DHCP relay. When a client first activates or moves = =0A= into a new domain, DHCP message are best relayed to a central = server=0A= (such as the Domain Agent in Figure 1); however, when users roaming = =0A= among subnets within a domain DHCP message may best be handled =0A= locally. This would require no change in DHCP functionality; only a = =0A= change in allowable application.=0A= =0A= The goal is to allow a subnet proxy to act as both a relay and =0A= server, depending on a client's status.=0A= =0A= =0A= 3.7 Dynamically changing server (and relay) parameters=0A= =0A= In some networks it may be desirable to dynamically change the=0A= preconfigured information in DHCP servers (and relay agents). For=0A= example, the address-pool may change if a topology change occurs =0A= [DAAP]. While DHCP should have nothing to do with updating=0A= address-pools, it should be able to handle dynamic changes in this = =0A= information. If an external application changed the information, =0A= DHCP should gracefully handle the change (e.g., it may immediately = =0A= update all its clients). This would require no change in DHCP =0A= protocol, only that: a) there is a common configuration framework=0A= (e.g., [DHCL]), and b) that DHCP servers and relay agents allow =0A= dynamic changes in preconfigured information.=0A= =0A= The goal is to allow dynamic modification of DHCP server (and = relay)=0A= configured parameters, such as the address-pool, by an external=0A= entity.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 11]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= 4 Discussion=0A= =0A= The purpose of this draft is to stimulate discussion and solicit=0A= feedback on enhancing DHCP into new environments. These = environments=0A= include roaming users who do not need transparent address binding=0A= (e.g., a mobile web browser) or commercial service providers whose = =0A= access network provides framing (e.g., a cable access network). =0A= Given the large paradigm shift created by these new environments, = it=0A= is an open question on how to achieve these changes. At the highest = =0A= level we could slowly enhance DHCP, while maintaining backwards =0A= compatibility. A more radical approach would be the creation of a = =0A= sister protocol such as DRCP [DRCP]. We have not given specific =0A= approaches or mechanisms here, except as examples, because we =0A= initially want to focus on the requirements. =0A= =0A= =0A= =0A= 5. Acknowledgments=0A= =0A= The authors acknowledge the contributions of other members of the=0A= ITSUMO (Internet Technologies Supporting Universal Mobile = Operation)=0A= team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari, = =0A= S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and =0A= Toshiba America Research Incorporated (T. Kodama). Also thanks to=0A= Steve Gonczi of Process Software for his helpful suggestions. =0A= =0A= The initial ideas came out of a project on complete network=0A= autoconfiguration within a domain [DAAP], funded by the U.S. Army = =0A= Research Laboratory (ARL) under the Advanced Telecommunications = and=0A= Information Distribution Research Program (ATIRP) Consortium.=0A= =0A= =0A= =0A= 6. References=0A= =0A= [AAAD] P. Calhoun and A. Rubens, "DIAMETER Base Protocol," = Internet=0A= draft, Work in Progress, Nov 1998. =0A= =0A= [AAAR] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote=0A= Authentication Dial in User Service (RADIUS)," Request for=0A= Comments 2138, Apr 1997.=0A= =0A= [BOO1] B. Croft & J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC = 951,=0A= Stanford and SUN Microsystems, September 1985.=0A= =0A= [BOO2] Wimer, W., "Clarifications and Extensions for the = Bootstrap=0A= Protocol", RFC 1542, Carnegie Mellon University, October = 1993.=0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 12]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= [BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC = 1534,=0A= Bucknell University, October 1993.=0A= =0A= [CEL] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", = Internet=0A= draft, , Work in progress, = =0A= November 1998. =0A= =0A= [DAAP] A. McAuley and K. Manousakis, "Self-Configuring Networks."=0A= To appear Proc. of 4'th Advanced Telecommunications and=0A= Information Distribution Research (ATIRP) Conference,=0A= University of Maryland, March 2000.=0A= =0A= [DHC] R. Droms, "Dynamic Host Configuration Protocol," Request = for=0A= Comments 2131, Mar 1997.=0A= =0A= [DHCA] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", =0A= , Work in progress, =0A= October 1999.=0A= =0A= [DHCB] B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC load balancing = =0A= algorithm," , Work in progress, = =0A= October 1999.=0A= =0A= [DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS,"=0A= , Work in progress, June = 1999.=0A= =0A= [DHCL] A. Bennett, B. Volz, A. Westerinen, "DHCP Schema for = LDAP,"=0A= , Work in progress, June = 1999.=0A= =0A= [DHCF] R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. = Rabil,=0A= M. Dooley, A. Kapur, "DHCP Failover Protocol," =0A= , Work in progress,=0A= October 1999.=0A= =0A= [DHCR] P. De Schrijver, Y. T'Joens, C. Hublet, "Dynamic host =0A= configuration : DHCP reconfigure extension," =0A= , Work in progress,=0A= March 2000.=0A= =0A= [DHCZ] S. Das, A. McAuley, S.Baba, and Y.Shobatake, = "Authentication,=0A= Authorization, and Accounting Requirements for Roaming Nodes = =0A= using DHCP," , Work in =0A= Progress, March 2000.=0A= =0A= [DRCP] A. McAuley, S. Das, S.Baba, and Y.Shobatake, "Dynamic =0A= Registration and Configuration Protocol (DRCP),"=0A= , Work in Progress, October = 1999.=0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 13]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= =0A= [HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP = micro-=0A= mobility support using HAWAII", =0A= , Work in = progress,=0A= June 1999.=0A= =0A= [MIP] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.=0A= =0A= [MIP6] D. Johnson and C. Perkins, "Mobility Support in IPv6," =0A= , Work in Progress, Oct = 1999.=0A= =0A= [MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, = =0A= Authorization, and Accounting Requirements,"=0A= , Work in progress,=0A= October 1999. =0A= =0A= [MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos, = =0A= "Requirements on Mobile IP from a Cellular Perspective,"=0A= , Work in = =0A= progress, June 1999.=0A= =0A= [MIPD] P. Calhoun and C.E. Perkins, "DIAMETER Mobile IP = Extensions,"=0A= Internet draft, Work in Progress, Nov 1998.=0A= =0A= [MIPN] P. Calhoun and C.E. Perkins, "Mobile IP Network Access=0A= Identifier Extension," = =0A= Work in progress, October 1999.=0A= =0A= [MIPS] B. Patil, R. Narayanan & E. Qaddoura, "Security = Requirements/=0A= Implementaion Guidelines for Mobile IP using IP security"=0A= Internet draft, Work in Progress, June,1999.=0A= =0A= [MIPT] Tom Hiller, et al. "3G Wireless Data Provider Architecture = =0A= Using Mobile IP and AAA," = ,=0A= Internet draft, Work in progress, October 1999.=0A= =0A= [NAI] B. Aboba and M. A. Beadles, "The network access = identifier,"=0A= RFC 2486, January 1999.=0A= =0A= [PPP] W. Simpson, "The Point to Point Protocol (PPP),: Internet STD = =0A= 51, July 1994.=0A= =0A= [PPPE] L. Mamakos, et al., "Method for Transmitting PPP Over = Ethernet=0A= (PPPoE)," RFC 2516, February 1999.=0A= =0A= [PPPL] W. Townsley, et al, "Layer Two Tunneling Protocol L2TP," RFC = =0A= 2661, August 1999.=0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 14]=0A= =0C=0A= Internet Draft Requirements for Extending DHCP March 3, = 2000=0A= =0A= =0A= [REQ] S. Bradner, "Key words for use in RFCs to Indicate = Requirement=0A= Levels," RFC-2119, March 1997.=0A= =0A= [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: = =0A= Session Initiation Protocol," RFC 2543, March 1999.=0A= =0A= [SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using = SIP",=0A= Proc. of second ACM International Workshop on Wireless=0A= Mobile Multimedia (WOWMOM'99), pp 76-82, August, 1999.=0A= =0A= =0A= =0A= 7. Authors' Addresses=0A= =0A= Anthony J. McAuley =0A= MCC 1C235B, Telcordia=0A= 445 South Street, Morristown, NJ 07960=0A= Phone: +1 973 829 4698=0A= email: mcauley@research.telcordia.com=0A= =0A= =0A= Subir Das=0A= MCC 1D210R, Telcordia=0A= 445 South Street, Morristown, NJ 07960=0A= Phone: +1 973 829 4959=0A= email: subir@research.telcordia.com=0A= =0A= =0A= Shinichi Baba=0A= Toshiba America Research Inc.=0A= P.O. Box 136 Convent Station, NJ 07961-0136=0A= Phone: +1 973 829 4759 =0A= email: sbaba@tari.toshiba.com=0A= =0A= =0A= Yasuro Shobatake=0A= Toshiba America Research Inc.=0A= P.O. Box 136 Convent Station, NJ 07961-0136=0A= Phone: +1 973 829 3951=0A= email: yasuro.shobatake@toshiba.co.jp=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ITSUMO Group Expires August 2000 [Page = 15]=0A= ------_=_NextPart_000_01C0C67B.3923F9F0-- From owner-dhcp-v4@bucknell.edu Mon Apr 16 16:14:06 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13080 for ; Mon, 16 Apr 2001 16:14:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3GK4le29129; Mon, 16 Apr 2001 16:04:47 -0400 (EDT) Received: from plato.protechpts.com ([209.161.92.100]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3GK4ae29693 for ; Mon, 16 Apr 2001 16:04:37 -0400 (EDT) Received: from HFG (HFG [192.168.100.4]) by plato.protechpts.com (NTMail 5.06.0016/QS1090.00.89c82519) with ESMTP id cedacaaa for dhcp-v4@bucknell.edu; Mon, 16 Apr 2001 16:07:44 -0400 Message-Id: <5.0.2.1.0.20010416160211.033c0d70@mail.protechpts.com> X-Sender: hgottfried@mail.protechpts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 16 Apr 2001 16:03:46 -0400 To: DHCPv4 discussion list From: Hal F Gottfried Subject: DHCP Scopes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: hgottfried@protechpts.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN One of my colleagues has a DHCP server , with two scopes on it. One of them is a public IP range for interoffice use and one is a private range for other machines in a separate subnet. What is the easiest way to make the two ranges available , since it only seems to be pulling from one range. From owner-dhcp-v4@bucknell.edu Wed Apr 18 09:12:22 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10633 for ; Wed, 18 Apr 2001 09:12:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3ID3fe14849; Wed, 18 Apr 2001 09:03:41 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3ID3Qe01084 for ; Wed, 18 Apr 2001 09:03:26 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA18692 for ; Wed, 18 Apr 2001 08:57:51 -0500 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3ID3A587520 for ; Wed, 18 Apr 2001 09:03:11 -0400 Importance: Normal Subject: reserve hostname in DHCP/DDNS To: DHCPv4 discussion list X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Hannah O Day" Date: Wed, 18 Apr 2001 08:02:50 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.6a |January 17, 2001) at 04/18/2001 08:02:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hope some of you can help me with this one: I'm trying to reserve a hostname for a particular client by using the client statement and option 12. The syntax looks like below: client 1 MACaddress IPaddress { option 12 uniquehostname } >From what I understand this should prevent other users from using this "uniquehostname" since it's reserved for this particular Mac. But from what I observed, it's not working. I can still use this same hostname for other Macs. Another question I have is will this client statement work in a global container level? The purpose is to prevent clients crossing subnets from using the same hostname. Thank you! Hannah Day ----- I/T Network Support, From owner-dhcp-v4@bucknell.edu Thu Apr 19 05:31:45 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09259 for ; Thu, 19 Apr 2001 05:31:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3J9Oje02872; Thu, 19 Apr 2001 05:24:45 -0400 (EDT) Received: from relay02.rabobank.nl (relay02.rabobank.nl [145.72.69.21]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3J9OTe22570 for ; Thu, 19 Apr 2001 05:24:29 -0400 (EDT) Received: from 172.30.65.73 by relay02.rabobank.nl with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 19 Apr 2001 11:17:30 +0200 X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343 Received: by sol.rf.rabobank.nl with Internet Mail Service (5.5.2653.19) id <2QYLVN8T>; Thu, 19 Apr 2001 11:24:12 +0200 Message-ID: From: "Boersma, A (Abe)" To: DHCPv4 discussion list Subject: Performing Gateway Round Robin using DHCP Date: Thu, 19 Apr 2001 11:24:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 16C072A017952-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Reply-To: A.Boersma@rf.rabobank.nl Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi All, I have a question. Is it possible to for instance enter 2 routers in a template and RoundRobin the IP addresses every time the server receives a DHCP request. In other words, i have to gateways on a subnet and i wish to loadbalance the use for those routers using HDCP Thanks Abe RabobankICT the Netherlands X Abe Boersma Rabobank ICT Netwerkbedrijf / IP Services Laan van Eikenstein 9 3705 AR Zeist Tel: +31 (030)-2154974 Fax: +31 (030)-2151986 A.Boersma@rf.rabobank.nl ================================================ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. ================================================ The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. From owner-dhcp-v4@bucknell.edu Thu Apr 19 11:24:18 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12624 for ; Thu, 19 Apr 2001 11:24:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3JFCwe23873; Thu, 19 Apr 2001 11:12:58 -0400 (EDT) Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3JFCne18210 for ; Thu, 19 Apr 2001 11:12:50 -0400 (EDT) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 08:17:52 -0700 Message-ID: <716D440F8C29D311991100A0C92048740106A6F3@GIDGET.INCOGNITO.COM> From: "Kostur, Andre" To: DHCPv4 discussion list Subject: RE: Performing Gateway Round Robin using DHCP Date: Thu, 19 Apr 2001 08:17:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Andre@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN That's beyond the scope of the DHCP protocol (which is the topic for this mailing list). You would have to find a particular vendor's implementation of DHCP that would do the round robin. -----Original Message----- From: Boersma, A (Abe) [mailto:A.Boersma@rf.rabobank.nl] Sent: Thursday, April 19, 2001 2:24 AM To: DHCPv4 discussion list Subject: Performing Gateway Round Robin using DHCP Hi All, I have a question. Is it possible to for instance enter 2 routers in a template and RoundRobin the IP addresses every time the server receives a DHCP request. In other words, i have to gateways on a subnet and i wish to loadbalance the use for those routers using HDCP Thanks Abe RabobankICT the Netherlands X Abe Boersma Rabobank ICT Netwerkbedrijf / IP Services Laan van Eikenstein 9 3705 AR Zeist Tel: +31 (030)-2154974 Fax: +31 (030)-2151986 A.Boersma@rf.rabobank.nl ================================================ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. ================================================ The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. From owner-dhcp-v4@bucknell.edu Fri Apr 20 10:18:17 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12326 for ; Fri, 20 Apr 2001 10:18:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3KE17e12098; Fri, 20 Apr 2001 10:01:07 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3KE11e32734 for ; Fri, 20 Apr 2001 10:01:01 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA89930 for ; Fri, 20 Apr 2001 09:59:16 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA27388 for ; Fri, 20 Apr 2001 09:55:29 -0400 Importance: Normal Subject: reserve hostname in DHCP/DDNS To: DHCPv4 discussion list X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Hannah O Day" Date: Fri, 20 Apr 2001 09:00:03 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.6a |January 17, 2001) at 04/20/2001 09:00:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I sent the below note a couple of days ago and haven't heard anything back from anyone yet. Could anyone point me some directions? Thanks! Hannah O Day 04/18/2001 08:02 AM To: DHCPv4 discussion list cc: From: Hannah O Day/Rochester/IBM@IBMUS Subject: reserve hostname in DHCP/DDNS Importance: Normal Hope some of you can help me with this one: I'm trying to reserve a hostname for a particular client by using the client statement and option 12. The syntax looks like below: client 1 MACaddress IPaddress { option 12 uniquehostname } >From what I understand this should prevent other users from using this "uniquehostname" since it's reserved for this particular Mac. But from what I observed, it's not working. I can still use this same hostname for other Macs. Another question I have is will this client statement work in a global container level? The purpose is to prevent clients crossing subnets from using the same hostname. Thank you! Hannah Day ----- I/T Network Support, From owner-dhcp-v4@bucknell.edu Tue Apr 24 14:40:27 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12175 for ; Tue, 24 Apr 2001 14:40:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3OIWMe11441; Tue, 24 Apr 2001 14:32:23 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3OIWKe23137 for ; Tue, 24 Apr 2001 14:32:20 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA35688; Tue, 24 Apr 2001 14:31:30 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA23788; Tue, 24 Apr 2001 14:31:32 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA09411; Tue, 24 Apr 2001 14:31:02 -0400 Message-Id: <200104241831.OAA09411@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: "Marcus Leech" Subject: draft-ietf-ipsec-dhcp-09.txt Date: Tue, 24 Apr 2001 14:31:02 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN While reviewing this document for the IESG, I came up with some questions that I'd like the DHC WG to comment on. i.e., this document seems to call for changes to existing DHCP practice, and the need for such changes does not seem properly motivated (at least to me). I would appreciate it if folks from the DHC WG would provide their perspective. I have a basic question/concern with one aspect of this document, namely its use of the chaddr field, the client identifier option, and relay agents. Background (to be sure I have this right). In DHCPv4, the chaddr field always has the link-layer address of the client in it. The relay agent needs this information (together with the giaddr field) to determine how to forward a DHCP response from the DHCP server back to the client (i.e., the giaddr field identifies the interface, the chaddr field is the link-layer address to use). (Actually, broadcast can also be used, but in the case of IPsec tunnels, that seems a non-starter.) In most cases the chaddr value also serves as the way to identify a client to the DHCP server from the perspective of which parameters to assign. However, the client identifier option allows the client to specify an alternate way of identifying itself to the DHCP server, one that doesn't use the chaddr value. In such cases, the chaddr field may still needed by the relay agent to forward DHCP messages from the server to the client. This document seems to be rather unclear about how it uses these values. In particular, it seems to provide a set of options rather than one clear way. I think this needlessly complicates the relay agent. Specifically, the chaddr field (together with the giaddr field) is no longer sufficient information to forward packets from the DHCP server to the client, and the document suggests that relay agents will need to maintain state in order to properly forward packets to clients. I believe this is a change to existing DHCP practice. > differentiate VPN from non-VPN requests. The chaddr field of the > DHCPDISCOVER SHOULD include a unique identifier. The client MUST use > the same chaddr field in all subsequent messages within the same DHCPv4 > exchange. This permits the use of DHCP Relay load balancing as described > in [19]. In addition, the chaddr SHOULD be persistent between reboots so > that the DHCP server will be able to re-assign the same address if The above doesn't seem quite what is needed. First, shouldn't it be a MUST rather than a SHOULD? What you might point out is that one can't guarantee that it is unique. Making it a SHOULD (per 2026) implies that there may be good reasons to not choose a unique identifier and an implementation might choose not to send one. If that is the case, an explanation would help. I.e., the DHCP server won't be happy if identifiers aren't unique enough. This is a basic DHCP assumption. Also, the load balancing stuff that used to be in the DHCP failover document has been removed and is now standalone (see RFC 3074). It is transparent to the client, so I don't see why anything in this document needs to be done to support it (as the above wording suggests) > 6.2. DHCPOFFER message processing > > Typically, the security gateway will also store the xid and the chaddr > gleaned from the DHCPDISCOVER in a table so as to be able to route the > corresponding DHCPOFFER message(s) back to the remote host. This would appear to be a fundamental change in relay agent model compared to standard DHCP. That is, traditional relay agents are stateless. All the info that a relay agent needs in order to relay DHCP packets is contained in those packets. No per-client state is needed. The above text suggests that the relay agent caches the chaddr field in order to be able to route back DHCP responses. Why is this needed? Isn't this info in the packet that needs to be relayed? The answer appears to be no, as the chaddr field as defined in this document isn't sufficiently useful for this. Wouldn't it be better to (say) have the relay agent add a relay agent option that includes information about the SA over which the packet was received? When the server responds, that relay agent option could contain the information needed properly forward the packet. This would be consistent with existing DHCP specifications and would eliminate the need for the relay agent to maintain per-client state. > For use in DHCv4 configuration of IPSEC tunnel mode, the client- > identifier option SHOULD be included and set to something that is unique > and persistent across reboots. Possibilities include: > > a) The htype/chaddr combination, if a LAN interface is present. > > b) The machine FQDN concatenated with an interface number. > > c) The user FQDN as determined from the user's NAI or certificate, > concatenated with an interface number. Another possiblity: why not just make it a MUST that a client identifier option be used (i.e., this is the approach taken by RFC 2855), and then have the chaddr field be the IPv4 (public) address of the client? If this were done, the relay agent would just do its normal processing. I.e., the IPv4 address would be who it forwards the packet too. The remaining comments are more editorial in nature. > concatenating H'4OO0', the IPv4 address of the interface supplying Do you mean 0x4000 ?? > the vendor-class-identifier option; the vendor-specific information > option; the subnet selection option [15] or the host name option [18]. Citing ralph and ted's book here? yikes! We should be citing the definitive source, i.e., RFCs!!! The spelling of IPsec isn't consistent. The document uses "Ipsec" and "IPSEC". I believe the preferred spelling is IPsec The abstract is a verbatim copy of the introduction. This shouldn't be the case. The wording surrounding DHCP failover wording seems a bit weird. Note that the DHPC failover mechanisms are transparent to DHCP clients. When failover is present, it is just a private thing between DHCP servers. Having this document cite DHCP failover as something it supports or helps, seems a stretch. The comparison between DHCP and IKECFG seems a bit long-winded. Somewhat hidden, is the assumption that everyone runs DHCP on the enterprise, including those folks using IKECFG. From that assumption, its pretty clear that having an all DHCP solution would avoid many problems that would be present if IKECFG and DHCP needed to sync up behind the scenes. Can't you just come out and say that? (Actually, I personally don't see much reason to include the comparison/justificaiton -- the document itself has chosen DHCP). Thomas From owner-dhcp-v4@bucknell.edu Tue Apr 24 18:40:50 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16999 for ; Tue, 24 Apr 2001 18:40:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3OMWoe09412; Tue, 24 Apr 2001 18:32:50 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3OMWfe06713 for ; Tue, 24 Apr 2001 18:32:42 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA84862; Tue, 24 Apr 2001 15:24:45 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 24 Apr 2001 15:24:45 -0700 (PDT) From: Bernard Aboba To: DHCPv4 discussion list cc: DHCPv4 discussion list , Marcus Leech , aboba@internaut.com Subject: Re: draft-ietf-ipsec-dhcp-09.txt In-Reply-To: <200104241831.OAA09411@rotala.raleigh.ibm.com> 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 > The above doesn't seem quite what is needed. First, shouldn't it be a > MUST rather than a SHOULD? What you might point out is that one can't > guarantee that it is unique. I agree. > Also, the load balancing stuff that used to be in the DHCP failover > document has been removed and is now standalone (see RFC 3074). It is > transparent to the client, so I don't see why anything in this > document needs to be done to support it (as the above wording > suggests) The requirement is that the chaddr be consistent throughout the DHCP conversation. > Wouldn't it be better to (say) have the relay agent add a relay agent > option that includes information about the SA over which the packet > was received? Yes, this would be better in my opinion. Then the relay would not need to keep state. > Another possiblity: why not just make it a MUST that a client > identifier option be used (i.e., this is the approach taken by RFC > 2855), and then have the chaddr field be the IPv4 (public) address of > the client? If this were done, the relay agent would just do its > normal processing. I.e., the IPv4 address would be who it forwards the > packet too. Remember, the IPv4 address may not be unique for systems behind a NAT, and you'd want two systems doing VPN from behind the same NAT to obtain different IP addresses. So I don't think this is a good idea. From owner-dhcp-v4@bucknell.edu Wed Apr 25 08:10:15 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12136 for ; Wed, 25 Apr 2001 08:10:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3PC3We21471; Wed, 25 Apr 2001 08:03:32 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3PC3Pe20172 for ; Wed, 25 Apr 2001 08:03:26 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 25 Apr 2001 17:38:44 +0530 Received: from radhard (radhard.future.futsoft.com [10.6.2.24]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f3PBtOe29899 for ; Wed, 25 Apr 2001 17:25:24 +0530 Received: by localhost with Microsoft MAPI; Wed, 25 Apr 2001 17:17:13 +0530 Message-Id: <01C0CDAB.920CFBC0.radhard@future.futsoft.com> From: Radha Rani Reply-To: "radhard@future.futsoft.com" To: DHCPv4 discussion list Subject: Doubts in DHCP Relay Agent Date: Wed, 25 Apr 2001 17:17:10 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, Please consider the following scenario Consider a router with two Ethernet interfaces and one ATM/ADSL interface two Ethernet interfaces are connected to different LANs. The ATM interface is connected to an ISP. DHCP Relay Agent is running in the Router. Now the scenario is like this. The DHCP messages from the DHCP client (LAN side) will be forwarded by the DHCP Relay agent to the DHCP Server running at ISP (WAN side). 1. Which address the DHCP Relay Agent will fill in giaddr field while forwarding the DHCP packets from DHCP Client to the DHCP Server? 2. On what basis the DHCP Server will assign the IP addresses to the LAN Users? 3. If the LAN is in 10.0.0.0 network, will the DHCP Server assigns private or global address? 4. If the address allocated by DHCP Server is a global address then is it necessary to add a host route in the router, where DHCP Relay agent is functioning? If the route is added then how the route will be removed from the router when the lease expires? Because DHCP Relay Agent will not have the lease information. Thank you in Advance Radha From owner-dhcp-v4@bucknell.edu Wed Apr 25 11:02:12 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18765 for ; Wed, 25 Apr 2001 11:02:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3PEuDe11467; Wed, 25 Apr 2001 10:56:13 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3PEu1e16938 for ; Wed, 25 Apr 2001 10:56:01 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA26702; Wed, 25 Apr 2001 10:51:55 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA31496; Wed, 25 Apr 2001 10:50:59 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA12087; Wed, 25 Apr 2001 10:50:15 -0400 Message-Id: <200104251450.KAA12087@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list , Marcus Leech Subject: Re: draft-ietf-ipsec-dhcp-09.txt In-Reply-To: Message from Bernard Aboba of "Tue, 24 Apr 2001 15:24:45 PDT." Date: Wed, 25 Apr 2001 10:50:15 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernard Aboba writes: > > Also, the load balancing stuff that used to be in the DHCP failover > > document has been removed and is now standalone (see RFC 3074). It is > > transparent to the client, so I don't see why anything in this > > document needs to be done to support it (as the above wording > > suggests) > The requirement is that the chaddr be consistent throughout the DHCP > conversation. Right. It would be good to just state that directly. > > Another possiblity: why not just make it a MUST that a client > > identifier option be used (i.e., this is the approach taken by RFC > > 2855), and then have the chaddr field be the IPv4 (public) address of > > the client? If this were done, the relay agent would just do its > > normal processing. I.e., the IPv4 address would be who it forwards the > > packet too. > Remember, the IPv4 address may not be unique for systems behind a NAT, and > you'd want two systems doing VPN from behind the same NAT to obtain > different IP addresses. So I don't think this is a good idea. I'm assuming we're talking about the client address here. But if the IPv4 client address is NATted, how will it be able to set up an IPsec tunnel between the client and the security gateway? I.e., the outer IPsec header for packets going between the client and security gateway cannot traverse a NAT box. At best this would seem to be a gray area; does IKE work through a NAT box in practice? But my thinking here in any case is that the client identifier option indicates WHO the client is (to the DHCP server) and the chaddr corresponds to whatever IP address the client is using at that time. That address needs to be reachable from the security gateway in any case. Oh, and DHCP will have trouble going through NAT boxes if they do port mapping, I think, as both the source and destination port numbers are fixed per the protocol spec. Thomas From owner-dhcp-v4@bucknell.edu Wed Apr 25 14:17:05 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25234 for ; Wed, 25 Apr 2001 14:17:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3PI5pe27462; Wed, 25 Apr 2001 14:05:51 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3PI5be14897 for ; Wed, 25 Apr 2001 14:05:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA86320; Wed, 25 Apr 2001 10:55:37 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 25 Apr 2001 10:55:37 -0700 (PDT) From: Bernard Aboba To: DHCPv4 discussion list cc: DHCPv4 discussion list , Marcus Leech Subject: Re: draft-ietf-ipsec-dhcp-09.txt In-Reply-To: <200104251450.KAA12087@rotala.raleigh.ibm.com> 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 > I'm assuming we're talking about the client address here. But if the > IPv4 client address is NATted, how will it be able to set up an IPsec > tunnel between the client and the security gateway? I.e., the outer > IPsec header for packets going between the client and security gateway > cannot traverse a NAT box. At best this would seem to be a gray area; > does IKE work through a NAT box in practice? Surprisingly, Tunnel mode clients do work through NAT boxes in many cases. Remember, IPSEC ESP's message integrity check does not include the IP header so translating IP addresses will not break ESP tunnels. Unlike L2TP, w/tunnel mode there is no UDP header and therefore no (optional) checksum, or floating port problems. Assuming that the client negotiates "ANY to ANY" filters (most do), the only address dependency occurs due to the mismatch between the IKE identifiers and the source address. Most existing implementations ignore this. The end result is that a single tunnel mode client can work through a NAT, and this has become a big selling point for tunnel mode. Note that trying to get two clients to run behind a NAT generally won't work though. > Oh, and DHCP will have trouble going through NAT boxes if > they do port mapping, This isn't a problem because the DHCP packets travel *inside* the tunnel, not outside it, so they don't get translated. From owner-dhcp-v4@bucknell.edu Thu Apr 26 07:31:13 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28632 for ; Thu, 26 Apr 2001 07:31:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3QBKbe29638; Thu, 26 Apr 2001 07:20:37 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3QBKTe05801 for ; Thu, 26 Apr 2001 07:20:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27925; Thu, 26 Apr 2001 07:20:27 -0400 (EDT) Message-Id: <200104261120.HAA27925@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-dhcpv6-18.txt Date: Thu, 26 Apr 2001 07:20:27 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, R. Droms Filename : draft-ietf-dhc-dhcpv6-18.txt Pages : 58 Date : 25-Apr-01 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [13], and can be used separately or concurrently with the latter to obtain configuration parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-18.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-dhcpv6-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-18.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: <20010425142703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010425142703.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Mon Apr 30 17:01:58 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25949; Mon, 30 Apr 2001 17:01:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f3UKx1e28788; Mon, 30 Apr 2001 16:59:09 -0400 (EDT) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f3UKwWe30433 for ; Mon, 30 Apr 2001 16:58:32 -0400 (EDT) Received: from mr6.exu.ericsson.se. (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f3UKwG803273 for ; Mon, 30 Apr 2001 15:58:16 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3UKwFL17592 for ; Mon, 30 Apr 2001 15:58:15 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 30 15:58:14 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 15:58:14 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBA41@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Cc: "'dhcp-v6@bucknell.edu'" Subject: A6 and DNAME Date: Mon, 30 Apr 2001 15:58:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1B8.4258AFF0" 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_01C0D1B8.4258AFF0 Content-Type: text/plain; charset="iso-8859-1" Hi: One more item to add to the recent discussion (which I've only partially followed) on A6 and DNAME records is ... how are they created and used in the first place? If one assumes that IPv6 addresses are automatically generated (either using autoconfiguration or DHCPv6), then how does an A6 record with non-0 prefix length ever get added in the first place? There hasn't been any method developed (that I'm aware of) to communicate to a client or DHCPv6 server that it should register these addresses under a given prefix. Also, if it were to do this, what happens if the prefix is multi-homed yet the address allocated to the client isn't (only one of the prefixes is in use)? This would significantly complicate clients and DHCPv6 servers since they may have to pull together several addresses before being able to register under the non-0 prefix? And the failure modes (such as not getting one address because of DAD or other reasons) are difficult to deal with. Same happens with the PTR records and DNAME ... how is the client or DHCPv6 server told to use a particular DNAME to register? Seems to me that most clients and DHCPv6 servers will register with the full 128-bits and therefore this fancy stuff won't be used anyway - since nothing will be in place to set it up. Sure, we could add a DHCPv6 option to communicate these details. But, what about when DHCPv6 isn't used and autoconfiguration is used? Sorry if this has already been raised as an issue and I missed it. - Bernie Volz ------_=_NextPart_001_01C0D1B8.4258AFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A6 and DNAME

Hi:

One more item to add to the recent = discussion (which I've only partially followed) on A6 and DNAME records = is ... how are they created and used in the first place?

If one assumes that IPv6 addresses are = automatically generated (either using autoconfiguration or DHCPv6), = then how does an A6 record with non-0 prefix length ever get added in = the first place? There hasn't been any method developed (that I'm aware = of) to communicate to a client or DHCPv6 server that it should register = these addresses under a given prefix. Also, if it were to do this, what = happens if the prefix is multi-homed yet the address allocated to the = client isn't (only one of the prefixes is in use)? This would = significantly complicate clients and DHCPv6 servers since they may have = to pull together several addresses before being able to register under = the non-0 prefix? And the failure modes (such as not getting one = address because of DAD or other reasons) are difficult to deal = with.

Same happens with the PTR records and = DNAME ... how is the client or DHCPv6 server told to use a particular = DNAME to register?

Seems to me that most clients and = DHCPv6 servers will register with the full 128-bits and therefore this = fancy stuff won't be used anyway - since nothing will be in place to = set it up.

Sure, we could add a DHCPv6 option to = communicate these details. But, what about when DHCPv6 isn't used and = autoconfiguration is used?

Sorry if this has already been raised = as an issue and I missed it.

- Bernie Volz

------_=_NextPart_001_01C0D1B8.4258AFF0--