Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-03.txt

From: [email-masked]
Date: Mon, 24 Oct 2005 18:50:01 -0400

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 Server Identifier Override Suboption
	Author(s)	: R. Johnson, et al.
	Filename	: draft-ietf-dhc-server-override-03.txt
	Pages		: 10
	Date		: 2005-10-24
	
This memo defines a new suboption of the DHCP relay information
   option which allows the DHCP relay to specify a new value for the
   Server Identifier option, which is inserted by the DHCP Server.  This
   allows the DHCP relay to act as the actual DHCP server such that
   RENEW DHCPREQUESTs will come to the relay instead of going to the
   server directly.  This gives the relay the opportunity to include the
   Relay Agent option with appropriate suboptions even on DHCP RENEW
   messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-server-override-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-server-override-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.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Sanjeev Verma <[email-masked]>
Date: Tue, 25 Oct 2005 11:13:27 -0700

Few questions about the draft

1. Why do we want a suboption to be sent to DHCP server instead of
defining an optional and additional functionality on relay itself? That
is, why not let relay save server-id and change it on the fly in both
directions? If a relay is maintaining leases (raison d'etre for seeing
renews) then it should have memory/capacity enough to save some more
information about leases.

2. DHCP server can be configured with server-ids specific to interfaces
that it is serving. Isnt that an alternative to this draft? There might
be various reasons for not adopting this approach, but I think this
should find a mention in the draft. Or a reason, why this is not
recommended?

- Sanjeev.

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Andre Kostur <[email-masked]>
Date: Tue, 25 Oct 2005 11:22:06 -0700

> information about leases.
That would mess up any implementation of RFC 3118.  Basically the only 
thing that a Relay can "safely" modify is the GIADDR, and adding an 
Option 82.  Adjusting anything else would mess up implemenations of RFC 
3118.
> recommended.
The relay may be the only device that has enough information to decide 
on which subnet it wishes a particular client to reside on.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 25 Oct 2005 12:33:27 -0700

> information about leases.

One reason floats to the top of my head, RFC3118.

The relay agent option is data held in a conversation between the server
and relay, the other contents of the packet are between the client and
server...although some relays may find them informational, and do snoop
packet contents.

Moving away from this, making this line between these two different
conversations fuzzy, is bad juju I think.

> should find a mention in the draft. Or a reason, why this is not

Either configured, or can realize of its own accord that it needs to do
so.  If, as in the text below from the draft, the server deigns to use
relay agent options to decide how to configure the client...it should
include the relay by setting server-id to giaddr.  We don't need an
option for this, do we?  Providing an address produces flexibility, but
the giaddr should be an adequate target as well.  Is there a case where
the giaddr is insufficient?

Quoting the introduction;

   ... This means that the relay
   may not see the DHCP RENEWAL messages (depending upon network
   topology) and thus can not provide the same relay agent option
   information in the RENEWAL messages.

Which is why one "stashes" the relay agent information on persistent
state in the server corresponding to the leased address.  Upon renewals,
for cases where you usually operate on the relay agent options, you
consume the stashed values.

I think the authors intended to point out that this information may
change between renewals?  And the client's renewal packet may still
get to the server?  If so, in what circumstances?  This belongs in
the introduction I think, to argue the case for the existence of the
option.

I think to ask the relay to make a determination to stay in the loop
implies that the server is not concerned with keeping up to date on
the relay agent options, but rather that the relay is concerned with
staying in the loop so it can snoop.

This is also a fine thing, but needs to be the emphasis of the
introduction instead, and we need to talk about the reasons why a
relay might want to snoop, in case there are better ways to solve
those specific problems.

The most frequent reason I've heard people setup DHCPv4 relays to snoop
is to get and idea of "actively leased addresses" so that firewall rules
can close out unused addresses (so that people not registered with DHCP
get no IP routing).

In my opinion, this is better and more effectively handled directly by
the DHCP server, or better yet, by a pair of them acting in concert and
implementing a form of failover.

But that doesn't mean this isn't a valid solution.

I can't really think of any other reasons for a relay to desire
involvement.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 25 Oct 2005 12:39:24 -0700

> on which subnet it wishes a particular client to reside on.

By definition, it is precisely that, no "may be" around it.

But I don't see how this is topical, these are things covered by giaddrs
and other relay agent suboptions, so I think I've completely missed your
point...what am I missing?

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 25 Oct 2005 15:51:58 -0400

> implementing a form of failover.

In cases I've seen, it is an embedded device like a wireless access
point concentrator that does this snooping to implement DHCP-based
ACLs.  In many cases, there is no easy way for the DHCP server to
communicate ACLs to the embedded device.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 25 Oct 2005 15:21:25 -0700

> communicate ACLs to the embedded device.

In which case, it can do this anyway, without this option, because
it's directly connected to the clients.  See also 802.1x.

For layer3 and up...holding down addresses that haven't been allocated
to punish manual interveners...this is a routing problem, and is better
solved using routing protocols than dhcp snoop duct tape.