Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for DHCP"

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Apr 1999 13:28:10 -0400 (EDT)

> This is a WG last call for "The Subnet Selection Option for DHCP",
> <draft-ietf-dhc-subnet-option-01.txt>.  This document has been revised
> according to the comments from the WG discussion in Minneapolis, 3/99.
> According to the consensus of the WG, the document is now in WG last call
> prior to submission for acceptance as a Proposed Standard.

I have to admit that I still don't fully understand what this option
will be used for and in what scenario (e.g., I don't quite follow the
"control plane" vs. "switching plane" terminology). It would help if
the draft gave a concrete example environment where it is needed.

Also, who adds this field? Is it the client or the relay agent? If the
latter, should this be a normal DHCP option or a relay agent option?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 26 Apr 1999 13:57:53 -0400 (EDT)

> an example of such an environment is a RAS device that allocates addresses
> on behalf of its RAS clients. furthermore, the RAS clients are on subnet(s)
> that are not network connected (routed or direct) to the subnet that the
> dhcp server is on.  however, at least one subnet on the RAS device is
> network connected to the dhcp server for the purposes of allocating
> addresses.  the "switching plane" are the subnets that the RAS clients
> connect to.  the "control plane" is the subnet(s) that are network connected
> to the dhcp server.

OK. I think I get it. The "client" isn't really what we normally think
of as the client (i.e, the entity actually formulating the
request). That is, the actual end-point client may be running PPP to
the RAS, and the RAS wants addresses to send over the PPP link using
the PPP negotiation mechanism. Is this the scenario?

Also, is the reason there is no network connectivity between the
end-client and the DHCP server due to policy? Seems like there would
be sufficient connectivity. I.e., a layer-2 connection to the RAS
server, than layer 3 to the DHCP server. But this is precisely the
case that DHCP would seem to already handle.

Also, how many addresses can the same "client" request? I.e, if the
RAS makes a dozen requests over a period of time, how are those
allocations distinguished? Is it assumed that the DHCP "client" (i.e.,
the RAS not the end-client) uses a differnet client ID and/or MAC
addresses? Some text on this point would probably be useful to have in
the draft.

Finally, one other point. The option itself encodes a "subnet" as a
4-byte field. Seems to me like you need to include the network
mask. One can't reliably extract a subnet number of an address just by
looking at it in the general case. 

Thomas

---

From: "Glenn Waters" <[email-masked]>
Date: Mon, 26 Apr 1999 13:58:45 -0400 (EDT)

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: Monday, April 26, 1999 10:35
> To: Glenn Waters
> Cc: Multiple recipients of list
> Subject: Re: REMINDER: WG Last Call for "The Subnet Selection Option for
> DHCP"
>
>

yes, this is the scenario.

> case that DHCP would seem to already handle.

it is due to security (which is policy, but then again what isn't policy
these days in the IETF :).  there is not sufficient connectivy in that there
does not exist any routed network connectivity to the "RAS" subnets to/from
the DHCP server.  there is routed connectivity to the control plane portion
of the box.  the scenario where the RAS subnets cannot route to the subnet
of the DHCP server is in a ISP outsourcing environment where you do not want
customers having any type of access to the ISP's internal network.

> addresses? Some text on this point would probably be useful to have in

i could add this text if you feel it is really neccessary.  i am reluctant
to do so since the text really is describing how to do proxy dhcp services
and that is not the main point of this draft.

> looking at it in the general case.

dhcp servers know how to take an address without a mask and determine the
subnet for that address.  they can do this because the contain the topology
on the relevant pieces of the network.  dhcp servers must deal with the
giaddr field in exactly the same way as they must do so for this option.

> Thomas

thanks for you comments.  i can add the RAS example to the text of the
draft.  i can change the terms "control" and "switching" plane but would
like some suggestions (not neccessarily just from thomas) on some new terms.

/gww

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Apr 1999 17:50:56 -0400 (EDT)

> looking at it in the general case. 

That's what we do now!   This has to be dealt with by configuring the
server to know the layout, including subnet masks, of the networks
it's serving.   I don't think this adds value - in reality it's going
to make the server's job harder, not easier, since the server will
then have to implement a different code path to use the subnet
selection option than it now uses to support the giaddr.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Apr 1999 08:41:38 -0400 (EDT)

> selection option than it now uses to support the giaddr.

Understood. I withdraw my suggestion.

Question: in the DHCP v6 discussions, at one point there was
discussion about putting the subnet mask (together with the relay
agent address) into DHCP packets so that the server would NOT need
have have explicit configuration knowledge of which subnet a relay
agent (and client) was on (i.e., the configuration information alluded
to above). The idea was that the DHCP packets would contain sufficient
information for the server to figure out which link the client is
on. This would presumably simplify configuration of servers.

Does the above actually make sense? Would this be a desirable feature
to have, or does it not really buy much operationally when looking at
the big picture?

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Apr 1999 11:59:38 -0400 (EDT)

> on. This would presumably simplify configuration of servers.

I don't know enough about DHCPv6 in particular to be sure, but my
inclination is to say that this is also a bad idea.  The DHCP server
administrator has to configure the DHCP server with addresses to
assign.  If there's any repository of the true state of the network,
it's going to be on the DHCP server (unless you also hack the relay
agent to include information about its secondary IP addresses in each
packet).  Pushing the configured state from the network *away* from
the central server seems to me like the opposite of what should be
done.   If the DHCP server could somehow automatically configure
itself without any operator intervention, maybe this would make sense,
but I don't think it can, and I think that just including the subnet
mask in the relayed packet doesn't make this any more possible.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Apr 1999 13:38:11 -0400 (EDT)

> customers having any type of access to the ISP's internal network.

Seems to me like we're splitting hairs here. One can have filters that
allow only DHCP packets to be relayed by the RAS and satisfy security
concerns. I.e., the RAS is a relay agent. If your security policy
doesn't like that model, should the DHCP protocol be bent to get
around management dictates? 

> and that is not the main point of this draft.

Seems to me that this draft takes a very definite stand in support of
a proxy DHCP service. I believe this is the first document to do so. I
think it would be good for the WG to think hard about whether it wants
to support this and to what degree. I'm not saying it shouldn't, just
that the WG should not blindly go forward without thinking through the
longer-term implications. I.e., will there be more options needed in
the future? Will the RAS want to ask for a block of addresses rather
than just one?

Thomas

---

From: "Glenn Waters" <[email-masked]>
Date: Tue, 27 Apr 1999 13:40:07 -0400 (EDT)

> a proxy DHCP service. I believe this is the first document to do so.

i am still reluctant to add anything about proxy service except possibly in
the context of an example.  the example could restate the dhcp requirement
about using a unique client-id for each address that is to be proxied.  i do
not want to state anything to formally since RFC2131 is quite clear on how a
server is to hand out addresses and none of that logic in RFC2131 changes as
a result of this document.

> the future?

i presented this draft to the WG in minneapolis and there was support from
most of the major dhcp vendors. i thus believe that the WG wants to support
this effort, however that is just my opinion.

> Will the RAS want to ask for a block of addresses rather
> than just one?

RAS's currently do ask for a block of addresses -- one at a time.  each
address request must contain a unique client-id.

> Thomas

cheers, /gww

---

From: "William Bartholomew" <[email-masked]>
Date: Tue, 27 Apr 1999 19:11:08 -0400 (EDT)

It is my opinion that ANY feature that simplify the use of DHCP across
multiple subnets is going to be of great benefit to the Internet community.

This is because subnetting is becomming a more and more common practice even
in smaller networks simply because it allows the
company/organisation/individual to enhance security or efficiency of their
network.

So if DHCP changes to allow ease of configuration in multiple subnets, or to
enhance communication between DHCP servers then this will be of great
benefit to smaller organisations that need the power of subnetting but need
flexibility and ease of management...

What other ways are there to make DHCP servers easier to manage in a smaller
yet complex environment????

Regards,

William D. Batholomew MCP MCSE CNA
Nemesis Software International
[email-masked]
(0418)199-661
Suite 175, 4/58 High Street
Toowong, QLD 4066
AUSTRALIA

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Apr 1999 20:42:20 -0400 (EDT)

> this effort, however that is just my opinion.

I think your impression was right.   I can think of some uses for this
option as well, and I'm very interested in implementing it.

> address request must contain a unique client-id.

Right, without seriously hacking the protocol, getting blocks of
addresses would be a pain.

			       _MelloN_