Subject: FWD: I-D ACTION:draft-itsumo-drcp-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 25 Jul 2000 10:21:01 -0400

Anyone had a look at this one? Comments?

Thomas

------- Forwarded Message

From: [email-masked]
To: IETF-Announce: ;
CC: [email-masked]
Date: Tue, 25 Jul 2000 06:32:37 -0400
Subject: I-D ACTION:draft-itsumo-drcp-01.txt
Reply-to: [email-masked]

--NextPart

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

	Title		: Dynamic Registration and Configuration Protocol (DRCP)
	Author(s)	: A. McAuley, S. Das, S. Madhani, 
                          S. Baba, Y. Shobatake
	Filename	: draft-itsumo-drcp-01.txt
	Pages		: 15
	Date		: 24-Jul-00
	
The Dynamic Host  Configuration  Protocol (DHCP) provides a framework
for  passing  configuration  information  to hosts  [DHC].  DHCP was,
however,  designed  for hosts on a fixed  LAN, not for nodes  roaming
among commercial  wireless networks.  A Mobile IP [MIP] Foreign Agent
gives some  powerful  plug and play  capability  for  roaming  hosts,
especially  when  combined  with some recent  proposals  [e.g., MIPA,
MIPC, MIPD, MIPN, HAW, CEL, TIA].  Mobile IP  functionality,  however
is not  always  needed  and  for  some  dynamic  networks  it  may be
undesirable to use Foreign Agents.  This draft proposes a lightweight
dynamic  configuration  protocol, called the Dynamic Registration and
Configuration  Protocol  (DRCP).  DRCP borrows  heavily from DHCP and
can switch to using DHCP protocol if only DHCP servers are present in
the  network;  but adds  features  critical  to roaming  users.  Most
importantly,  DRCP  allows  rapid  configuration  by  moving  address
consistency  checking  from the  critical  path.  Other new  features
allow:  a) clients to know when to get a new address  independent  of
the layer-2 access  technology,  b) efficient use of scarce  wireless
bandwidth, c) clients to be routers, d) dynamic  addition or deletion
of address  pools to any DRCP node, and e) message  exchange  without
broadcast.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-itsumo-drcp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-itsumo-drcp-01.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-itsumo-drcp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-itsumo-drcp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-itsumo-drcp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

------- End of Forwarded Message

---

From: Nathan Lane <[email-masked]>
Date: Tue, 25 Jul 2000 17:10:39 -0500

-----Original Message-----
	From:	Thomas Narten [SMTP:[email-masked]]
	Sent:	Tuesday, July 25, 2000 9:21 AM
	To:	DHCPv4 discussion list
	Subject:	FWD: I-D ACTION:draft-itsumo-drcp-01.txt

	Thomas

I don't see a real need for it when taking into account the body of work
already on DHC's plate in regards to addressing the issues.  In the list of
issues with DHCP that make a new protocol required, many, if not most, of
the issues are already addressed or being rapdily addressed by DHC.  One
major assertion in the draft is that broadcast is not used as much in DRCP
as in DHCP when indeed it is used and with a potentially worse impact to the
network than the very few broadcasts that are used in DHCP.

Issue #1 "Rapid client configuration": there is no reason DHCP cannot
configure a client in milliseconds.  It requires less aversion to dangerous
situations (duplicate IP address assignment), but it is very possible since
the current wording indicates "SHOULD", not "MUST".

Issue #3 "Rapid client reconfiguration": There is a draft out for a
DHCPFORCERENEW message already.  However, this is the only issue that is
more difficult to solve.  A broadcast-able FORCERENEW would be useful, but
highly dangerous (as is the DRCP equivalent.)

Issue #4 in the list "Allowing clients to be routers" is only due to
unfortunate wording in the old 2131 which I believe we've all agreed to
strike from the revised version.

My issues: The danger of duplicate IP address assignment is much higher with
DRCP as clients do not check the assignment.  Is this worth it?  An entirely
new protocol requires entirely new servers and infrastructure.  Is this
worth it when there is something already 80% workable with possibly zero
changes to the core protocol and a few minor extensions that are handled in
the least disruptive manner?  I believe most of the requirements could be
addressed by Category One or Category two options (or guidelines C, D and E)
as in "draft-ietf-dhc-option-review-and-namespace-02.txt".  FORCERENEW is
the odd-man out but I think it does not actually change DHCP itself, just
adds some requirements to the client that could be implemented separately.

Also, in "draft-ietf-dhc-enhance-requirements-00.txt", it is stated that
DHCP clients go to sleep until lease times deem a wakeup.  This is not
necessary and is not specified anywhere to my knowledge.  A DRCP client in
sleep mode would have to still listen for DRCP_ADVERTISEMENTS.  I do not see
how his is different from a DHCP client listening for a DHCPFORCERENEW.

-Nathan Lane

**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************

---

From: Tony McAuley <[email-masked]>
Date: Wed, 26 Jul 2000 13:39:21 -0400

Nathan and Thomas,

We agree that we should keep the benefits of DHCP if possible. We
are prototyping DRCP in order to gain some experience in the wireless
configuration arena and bring these experiences to  the DHC-WG.
I hope our work will at least give added momentum to some changes
already underway  (e.g., adding a DHCPFORCERENEW), but also will
give rise to some new features (e.g., an advertisement message).

However, adding wireless features to DHCP will increase the message
size which is a concern in the wireless environment. For example,
a DISCOVER message is about 20-30 bytes in DRCP versus 236 bytes
in DHCP. Beyond the bandwidth issue, which we believe is important,
I agree that many of the "DRCP features" can be (and are being) added
to DHCP without affecting the core protocol (e.g., allowing routers,
fast configuration, or allowing dynamic changes of address pools).
Others can be done with minor extensions (e.g., add DHCPFORCERENEW
or to add options about roaming services). However, our DRCP
advertisement message (to detect movement to a new subnet and allow
a roaming node to unicast to a server) does change the core protocol.

To address the danger of not ARP checking, our DRCP server does
some background checking of addresses it is going to allocate.

Any comments?

Thanks
 Tony & Subir

----------------------------------------------------------------------------

Anthony J. McAuley                     email:
[email-masked]
MCC 1C235B, Telcordia Technologies                    phone: +1 973 829
4698
445 South Street, Morristown, NJ 07960                  fax: +1 973 829
5888
----------------------------------------------------------------------------

> Subject: RE: I-D ACTION:draft-itsumo-drcp-01.txt
> Date: Tue, 25 Jul 2000 17:10:39 -0500
> From: Nathan Lane <[email-masked]>
> To: DHCPv4 discussion list <[email-masked]>
> CC: "[email-masked]'" <[email-masked]>
>