Subject: RE: draft on the "Subnet Selection Option for DHCP"

From: "Glenn Waters" <[email-masked]>
Date: Tue, 15 Jun 1999 13:40:11 -0400 (EDT)

[i copied the v4 list on this response since i have heard this question
before and i would like to get other comments on the usefulness of this
text.]

an example of who would use this option is a RAS device that is allocating
addresses for its clients.  in this case the RAS device would be allocating
addresses through DHCP and then handing those addresses out to its RAS
clients.

in this scenario the RAS device would be connected to a private "internal"
network on which the DHCP server would be located. the RAS device would also
be connected to one or more service providing "external" networks (i.e.: the
networks that the RAS clients are on). the internal network is not IP
connected to the external networks. however, inside the device there is
connectivity between the internal and external networks (e.g.: though the
backplane).

recall that this device is trying to allocate addresses for clients on the
client networks, but since there is no IP connectivity between the internal
network and the external networks the DHCP requests cannot originate from
the client networks because the responses from the DHCP server cannot be
routed back to the device. therefore the DHCP requests must originate from
the internal network.  the problem with originating the DHCP requests from
the internal network is that the DHCP server will allocate addresses on one
of the internal network's subnets, when what is required is an address on
one of the client subnets.

this is where the subnet selection option comes in.  the device would send
its DHCP requests on the internal subnet, but would include a subnet
selection option containing the address of the client subnet on which it
requires an address. the subnet selection option indicates to the DHCP
server to allocate the address on the requested subnet as opposed to the
normal operation of allocating the address on the subnet from which the DHCP
request originated.

does this help?  if so i could include this text in an example section of
the draft.

/gww

> -----Original Message-----
> From: Mike Dooley [mailto:[email-masked]]
> Sent: Tuesday, June 15, 1999 11:40
> To: Glenn Waters
> Subject: draft on the "Subnet Selection Option for DHCP"
>
>
> Glenn,
> I just finished reading your draft on the "Subnet Selection Option for
> DHCP".   Looks straight forward, only question I have is what
> types of DHCP
> clients do you forsee using this option.   I read the overview a couple of
> times, but I just don't get it ....  are these clients devices such as
> routers and switches, or actual workstations and PCs?    Can you give an
> example?
>
> Thanks,
> Mike
>
>
> ==========================================
> Michael Dooley
> Vice President of Product Development
> Lucent Technologies, IP Services Product Group
> [email-masked]
> ==========================================
>
>
>

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 Jun 1999 14:20:58 -0400 (EDT)

> addresses through DHCP and then handing those addresses out to its RAS

This seems like a good example to me.

It would also be useful with multicast DHCP clients, since they would
not require a forwarder (and would therefore not have a GIADDR field)
but would still have to be able to identify the network they are on.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Tue, 15 Jun 1999 14:20:22 -0400 (EDT)

Glenn--

this explanation is great!  it filled in the blanks in my understanding,
which were the source of the questions during the review period.  This
should probably be included in the draft....

--Barr

> ----------
> From: 	Glenn Waters[SMTP:[email-masked]]
> Sent: 	Tuesday, June 15, 1999 10:40 AM
> To: 	Multiple recipients of list
> Subject: 	RE: draft on the "Subnet Selection Option for DHCP"
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jun 1999 15:15:38 -0400 (EDT)

> It may be necessary to develop a new ICMP Subnet Query message. This
> would be the best solution, and would probably be useful to some other
> protocols as well.

Why not just use DHCP, then?   :')

If you want the benefit of multicast, have the relay agent be
receptive to multicast.  This solves the whole problem, and doesn't
require any major changes to any widely-deployed protocols, nor does
it require that networks that need to support both old and new clients
support two very different ways of doing DHCP.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jun 1999 15:13:46 -0400 (EDT)

> but would still have to be able to identify the network they are on.

How would they identify the network they were on?

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 Jun 1999 15:15:13 -0400 (EDT)

> How would they identify the network they were on?

A most excellent question, which I do not have a most excellent answer
for at the moment. The two obvious choices are (A) preconfigured at the
client, or (B) ask the network. (A) has major problems of course. As for
(B), there are lots of protocols already around that could provide parts
of this.

One possibility would be for the client to multicast a router discovery
message, which local routers would respond to. Since the query is
multicast, the client doesn't need an address. But since RDP responses
are unicasts, the clinet would need an address. The client would also
need a way to determine which portion of the addresses received back are
the network portion of the addresses. ICMP Subnet Mask query messages
are a solution to that as well. Don't worry: I don't think this is a
very workable approach either.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 Jun 1999 16:52:23 -0400 (EDT)

> support two very different ways of doing DHCP.

This is a good point, and one I have wrestled with myself. There are
lots of issues here though.

Suppose that a client sends a DHCPDISCOVER, which the BOOTP forwarder
picks up. What does the BOOTP forwarder do with it? Does it multicast
the message onto the next network? What does the next-hop forwarder do
with it? While it seems like this would certainly "work" it doesn't
address the primary benefit of using multicasts in the first place,
which is that we wouldn't need BOOTP forwarders at all.

BOOTP forwarders are problematic on many dimensions, and multicasting 
would solve most of those problems. They are difficult to maintain, and
require human management. They provide no value beyond replicating
queries and responses. Multicasts on the other hand eliminate (not
"solve" but "eliminate") all of those problems.

I'd rather see a pure-multicast query/response approach, simply because
it means we can eliminate the Internet's only mandatory proxy.

A non-trivial side benefit to multicast queries and responses would be
that server-store replication would be automated, since all of the
servers would see all of the transactions.

There are still loads of problems that have to be resolved. For example,
what should the default TTL be set to? The specs say that the default is
"one hop," which surely isn't enough. Sixteen will be too many for some
networks, and not enough for others.

Hard questions.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jun 1999 18:48:19 -0400 (EDT)

> which is that we wouldn't need BOOTP forwarders at all.

Eliminating relay agents using multicast would be very hard to do -
you need to accomplish quite a few things:

	(a) Get packets from the client to the server, when the client
	    doesn't have an IP address,
	(b) Provide a way for the client to determine what network
	    segment it's connected to, and
	(c) Get the response back to the client.

(a) is pretty tractable - we could continue with the current system of
using the 0.0.0.0 source address.

(b) is hard, as you've pointed out.  Because there's no relay agent,
the client has to figure out to what network segment it's attached to
before it sends its DHCP request, and before it has an IP address.
This is tricky to do, and I would argue that it may be impossible to
do without special layer-violating hacks to the router.

(c) is even harder to do.  If you unicast the packet back to the
client's new IP address, the router that receives it will try to ARP
for that IP address, which the client does not yet know, and so the
packet will just be dropped by the router when it gets no response.
In order to make this work, the DHCP server has to reach out and stuff
a value into the router's ARP cache, so that the router won't need to
ARP for the client.  But the DHCP server doesn't know the router's IP
address, because the packet was routed, not relayed.

So I think you're proposing that we introduce a total of three new
protocols in addition to multicast DHCP: one to allow the client to
get its network number without having an IP address, one to allow the
server to figure out what router initially forwarded a multicast
message (maybe the client would get this information in the first
protocol and stuff it in the DHCP packet) and one to allow the DHCP
server to reach out and stuff the ARP cache of the router (this can be
done with SNMP on some routers, but it's by no means ubuquitous).

This is starting to sound hard enough that we really need to do a
cost/benefit analysis and also try to see if there are any less
expensive ways to solve the same problem.

As far as a cost/benefit analysis goes, before you can benefit from
this protocol, you need to do the following:

	- Come up with all the protocols that are required to
	  implement this, and specify them to the point where they can
	  be implemented.
	- Get people (particularly Microsoft) to implement them.
	- Replace all existing DHCP clients with clients that know all
	  of the new protocols (you have to replace _all_ clients, or
	  you still have to have the old infrastructure around).
	- Install new software on all of your routers that supports
	  the new protocols, and probably in some cases replace old
	  routers with new ones where support for the new protocols is
	  not available.
	- Get multicast working on your network, if it is not already
	  working.
	- Update your DHCP server(s)

On the plus side, we have the following benefits:

	- Eliminates the need to configure relay agents on the routers
	  for every network on which DHCP is supported
	- Eliminates the Internet's only mandatory proxy

You mentioned that store/replication would be automated, since servers
will see all transactions, but in fact in this one instance there
would be no difference - the way DHCP relay agents and clients
currently work, all servers see all requests.  The multicast protocol
could mandate that clients multicast even renewals, and this would
extend the coverage somewhat, but I don't think it makes much
difference.  Since UDP isn't reliable (something multicast doesn't
change), we can't count on client requests to keep servers
synchronized - there still needs to be a reliable protocol keeping
servers in sync.

There's a truism that all of us who go to the IETF DHCP working group
meetings every four months recite to each other as we're considering
protocol changes: it's a lot easier to upgrade one server than 50,000
clients.  Realistically, any change that requires a change to the
client has to be thought of as a very long-term change.

If you are expecting to realize any real benefit before the year 2010,
I would say that your proposal is probably the wrong way to go,
because even assuming that Microsoft comes out with support for your
proposed protocols in the very first Windows release following Windows
2000, you will still need to keep the old infrastructure around until
the last Windows 2000 install is powered off, and that's not going to
be for a while.   How many of your clients still have WfW installed on
some of their systems?

If you are thinking of this as a circa 2010 solution, I applaud your
forward thinking.   However, I still think that there are simpler ways
to solve this problem, with somewhat smoother upgrade paths.   It
seems to me that the major problem you're trying to solve is that you
want to avoid having to configure a relay agent in every router on
every network in a large enterprise, and you especially want to avoid
having to maintain that configuration through manual intervention as
time goes by.   The problem that DHCP is "the Internet's only
mandatory proxy" is really an aesthetic problem, and I think it's a
mistake to believe that you can make DHCP aesthetically pleasing with
this one change.   Aside from the BOOTP packet format, DHCP is a
protocol that does something in IPv4 that no other protocol does, so
it's no surprise that it's a bit ugly.

I think the easy way to solve your problem is to simply have DHCP
relay agents do the multicast.  You still have to have a relay agent,
but you no longer have to configure it - just have it multicast the
DHCP request to all servers that are listening.  Because the relay
agent has an IP address, the server can still unicast its response.

This pretty much cleans up all the goo I described earlier - the DHCP
server no longer has to stuff the router's ARP table, you don't have
to have a special router (because the relay agent doesn't have to be
in the router), and the client doesn't have to be modified.  The best
thing about this is that it gives router vendors an immediate (if
temporary) competitive advantage if they are early implementors, so
implementation is likely to be quick and widespread, meaning that you
could probably deploy this protocol next year if you wanted to, and
I'd be glad to help you get the RFCs written to speed the process
along.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 Jun 1999 20:46:20 -0400 (EDT)

> using the 0.0.0.0 source address.

Yeah.

> before it sends its DHCP request, and before it has an IP address.

Easily resolvable with an ICMP Subnet Query message. The real question
is whether or not the addition of a new secondary service is cost
effective when I'm trying to eliminate another secondary service.

> (c) is even harder to do.

If the server multicasts the response back (not unicast), then the
response will get back to the segment that the request was sent from.
The client will only have to monitor the associated group address for a
matching response. This is actually very simple and another benefit of
using multicasts; the client-location logic is eliminated.

>         you still have to have the old infrastructure around).

I was going to wait until the whole thing was better cooked, but what
the heck: consider this para a proposal for a new "Version" option. Any
request that does not have 2 in this field should be treated as v1 DHCP
(ie, as it stands today).

>         routers with new ones where support for the new protocols is

The only new code would be an extension to ICMP. There would be no new
code required for anything else, assuming the router already supported
multicasts correctly.

>       - Get multicast working on your network, if it is not already

Its "on" already for every consumer-class OS and router shipped today.
There are still some devices that don't support it, but trust me when I
say that it would be more difficult to turn it "off" than it would be to
keep it on. Multicast routing is a different story, but that's routing
not forwarding.

>         - Update your DHCP server(s)

This is also straightforward. See a v2 request? Send a response to the
exact same address as the request came in on (the multicast, or in some
cases a broadcast address).

> currently work, all servers see all requests.

The difference is that in my (soon-to-be-proposed) model, the responses
are also multicast, allowing servers to witness the entire negotiation
process, which allows them to track what server assigned a specific
lease. This is a fundamental change over the unicast nature of today's
response model.

> Since UDP isn't reliable (something multicast doesn't change), we
> can't count on client requests to keep servers synchronized - there
> still needs to be a reliable protocol keeping servers in sync.

You are absolutely correct. However, this is much less challenging than
the problems being faced today. It is conceptually simple to use
something like IXFR to keep transaction logs in synch. "What's the
highest consecutively numbered transaction you've seen?" or "I seem to
have missed transaction number n, please send?"

> agent has an IP address, the server can still unicast its response.

You may be correct.

> I'd be glad to help you get the RFCs written to speed the process

Thanks for that.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 12:52:49 -0400 (EDT)

> effective when I'm trying to eliminate another secondary service.

How does the ICMP subnet query response get back to a requestor with
no IP address?  Am I just being clueless here?  This doesn't sound
easy to me.  It sounds like the router either has to stuff its ARP
table to get the response back to a client with an IP address of
0.0.0.0, or you have to violate layering and do the protocol at the
link layer instead of the IP layer.  And the ARP-table-stuffing seems
inherently unreliable - what if two clients try to boot in quick
succession?  They've both got the same IP address, and therefore the
same arp table entry, but they have different MAC addresses!

> using multicasts; the client-location logic is eliminated.

You still need to know where the client is in order to get it its IP
address.  And you're proposing that every single DHCP response be
multicast throughout the entire network now, and that every DHCP
client will receive every response for every other DHCP client.  On a
large network, this could result in a significant increase in DHCP
traffic on the average network segment.  Granted, it's not broadcast,
but it still consumes headroom on ethernets and bandwidth on WAN
links.  This doesn't seem like an improvement over the current state
of affairs.   Ask Barr-Hibbs if he'd be willing to tolerate this.

> (ie, as it stands today).

So you need to continue to replicate the old infrastructure, and you
get no benefit from the new protocol.   If this is the case, then
there's no point in deploying the new protocol - from a cost
perspective, as a businessman, I'm not going to deploy the protocol
unless I see some kind of benefit to doing so.

> code required for anything else, assuming the router already supported

Yes, if you assume that the DHCP server is going to multicast its
responses, and you assume that multicast routing to the DHCP multicast
address is statically configured to distribute such multicasts to all
supported networks.

> keep it on. Multicast routing is a different story, but that's routing

It is to multicast routing that I was referring.

> lease. This is a fundamental change over the unicast nature of today's

The fact that there are two opportunities for secondary servers to
hear about the transaction instead of one does not make the delivery
mechanism reliable - it simply halves the chances that the information
will be lost.  A reliable protocol requires acknowledgement of
transmissions.  So using multicast in this case does not change the
status quo with respect to secondary servers.

> have missed transaction number n, please send?"

Clients choose transaction IDs, not servers, and transaction IDs are
intended to be essentially random, not sequential, so implementing
something like what you're talking about would require substantial
changes to the existing protocol, well beyond the scope of the rest of
what you've discussed.   Given that a failover protocol exists, and
that there are implementations of an early version of the protocol
that work as intended, I see no benefit to extending the scope of your
proposal in this way, and I would argue that you should simply not
count this as a potential benefit to your proposed new protocol when
doing the cost/benefit analysis.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 1999 14:59:25 -0400 (EDT)

> no IP address?

Being datagram-oriented, ICMP query/response messages can be multicast
the same as UDP datagrams. The router discovery protocol uses ICMP
router solicitation and ICMP router advertisement messages over
multicast, as an example. It works quite well.

What this means for my theory is that the client and router (or other
local device like a server) can exchange subnet-specific data without
the client having an IP address, and without the server having to locate
the client (everything goes to the Class D addresss associated with the
protocol). The rest of it you know: Once the client knows the subnet
they are on, they can send off a multicast DHCP request, using their MAC
address as an event key. A server (or multiple servers) would respond by
sending DHCPOFFERS to the multicast address, which the client would
choose from and then multicast a DHCPREQUEST for the specific lease it
wanted. DHCPACK/DHCPNAK would also be sent over multicast, allowing
everybody to witness the process.

This is not that radical of a difference, but it has several benefits
over the current hop-along approach. It ain't nearly as hard as you're
making it. There are problems absolutely, but there are also benefits,
and none of the problems are unresolvable. In the end, the protocol will
be cleaner (I'll go ahead and commit to unpopularity by saying that the
current protocol is fundamentally bad by requiring a proxy).

> links.

The clients should leave the multicast group when they are not doing
renewals, which would limit the active members (and therefore the
networks that get the multicast traffic) to the current clients and any
servers. Actually, this would probably be the default behavior since
most stacks don't keep the DHCP client loaded (and bound) all the time.

If the DHCP client is not bound to the stack then there should not be an
active listener (reflected by an IGMP Leave message on client unload),
meaning no traffic would go to that subnet/switch-port anyway. So it's
probably not that much of a real concern in the first place.

There would be a slight increase in traffic over a non-replicated
installation with a pair of isolated servers. But it would be less
traffic than maintaining an n-way mesh of replication partners for the
same number of servers as defined in the current replication drafts.

> unless I see some kind of benefit to doing so.

Lower cost of setup and operation (bye-bye forwarders), and smoother
replication. This seems compelling to me (which is why I'm doing this).
Also, you only need to keep the existing stuff in place for as long as
you want to keep using it.

As far as "costs" of migration, the only thing that folks are going to
worry about (in my view) is whether or not their preferred server
software (and duh clients) are going to keep working. I don't think
anybody's going to cry about not having to turn on the forwarder for
their new subnets.

I'd like to push this along as an expiremental approach, and see where
it leads if nothing else. I think its doable and will offer better
service with less cost-of-ownership. Whether or not it goes beyond that
will be determined by the other people here. My goal is just to make it
work so that it can be studied as a possible alternative.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 15:01:46 -0400 (EDT)

> multicast, as an example. It works quite well.

Okay.

> A server (or multiple servers) would respond by

Again, this is going to create a huge amount of traffic, multicast to
every subnet that supports DHCP.   Is this really what you want?   Is
this really cleaner than having a relay agent?   I think the answer is
no.

> most stacks don't keep the DHCP client loaded (and bound) all the time.

Actually, most stacks do keep the DHCP client loaded and bound all the
time.  To what stacks are you referring?  If DHCP is in regular use,
and multicast is used as a delivery mechanism, then any network with a
significant number of DHCP clients is always, or at least frequently,
going to be getting DHCP multicasts.   If all the clients on that
network unbind from the multicast address when they don't need it,
then what you'll see on a large network with lots of DHCP clients is
kind of a pulsing effect, where whenever a client needs to do DHCP,
suddenly the amount of traffic on the network segment increases
substantially.   This will, admittedly, be less of a problem on small
networks, or networks where the DHCP multicast domain is carefully,
manually partitioned.

> same number of servers as defined in the current replication drafts.

Have you read the current failover protocol draft?

> replication. This seems compelling to me (which is why I'm doing this).

Right, but there's a cheaper way that accomplishes all your goals,
other than the goal of eliminating forwarders, for which I can find no
objective justification (and for which you've presented no objective
justification).  So why not go with the cheaper way?

> you want to keep using it.

Right, and that's going to be a very, very long time, given that
Windows 2000 won't be implementing your protocol (unless there's
something you and Peter Ford aren't telling us).

> I don't think anybody's going to cry about not having to turn on the
> forwarder for their new subnets.

Right, but the time when they won't have to turn on the forwarder for
new subnets is something like a decade in the future.  If you do the
multicast in the forwarder, you can stop configuring the forwarder
within a year or two, without requiring any changes in the client at
all.  Isn't this preferable?

> work so that it can be studied as a possible alternative.

I think we already know what we need to know to take the next step.
What is it that you hope to learn by implementing it?   I think we all
understand that it's possible to implement the protocol you've
proposed.   The problem is, will anybody *actually* implement it,
given the problems that it has?   And if it is implemented, will
anybody deploy it?   I think you should try to come up with an answer
to those two questions before you spend a lot of time implementing
something.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 1999 16:03:15 -0400 (EDT)

> > A server (or multiple servers) would respond by sending DHCPOFFERS
> > to the multicast address, which the client would choose from and
> > then multicast a DHCPREQUEST for the specific lease it wanted.
> > DHCPACK/DHCPNAK would also be sent over multicast, allowing
> this really cleaner than having a relay agent?   I think the answer
> is no.

Multicasting does not work that way (and please forgive the following
tutorial, it is to make a point). You don't send all traffic to all
subnets, but instead only send traffic to segments that have an active
listener (or have another router with an active listener). The process
of selection uses IGMP membership reports, with devices joining and
leaving multicast groups as needed. Routers and switches use these
reports to determine which subnet gets what traffic. This is invisible
to the application btw, with the stack handling the reports.

The result is that when a client needs to get/renew a lease, the agent
will bind to the stack which will send the IGMP join message. After the
job is done and the client unbinds, the stack will send the IGMP leave
message. Until the process is repeated, no multicast datagrams for that
specific Class D address will go to that switch port (or even to that
subnet if there aren't any other active listeners).

The only subnets that will get all traffic will be those that have
servers on them (since they will be permanently bound).

Filtering at the router solves the WAN utilization problem for people
that have it. Not very graceful I know, but this would have to be a
per-site call anyway (some folks will want it, others won't) and I can't
think of another solution that allows choice. Suggestions welcome.

> Actually, most stacks do keep the DHCP client loaded and bound all
> the time.  To what stacks are you referring?

If that's the case then this is a real problem. My understanding was
that Windows and MacOS did not stay bound, which is why things like
Client32 and DAVE could come in and renew the lease without involving
the DHCP agent. If the agent were permanently bound, they shouldn't be
able to bind to the stack? Am I wrong?

Looking at netstat output on NT4 shows no active UDP protos, and I am
using DHCP. The joinc agent is loaded but is not bound to the BOOTPC
port on my Digital UNIX 4.0d workstation. Same for dhcpagen on my
Solaris 7 box. I don't have a working Linux install at the moment.

If the ISC client is staying bound, well, I know one of the guys there
and he seems reasonable so maybe I'll ask him to change it <grin>.

> If DHCP is in regular use, and multicast is used as a delivery
> mechanism, then any network with a significant number of DHCP clients
> is always, or at least frequently, going to be getting DHCP
> multicasts.

Those same segments would also be getting the unicasts. There would be
an increase in per-segment utilization whenever multiple clients are in
renewal or lease mode at the same time. The level that we're talking
about is pretty trivial though. I would not call it substantial. This
should be monitored for statistical purposes however.

> Have you read the current failover protocol draft?

Not the absolute latest version, no.

> justification).  So why not go with the cheaper way?

I don't see how its cheaper. It just introduces an unnecessary element
(worse, the very element that I am trying to kill off).

> all.  Isn't this preferable?

A forwarder is not needed. I see no reason to mandate its use. I also
see no reason to FORBID its use, and there are scenarios where a proxy
would be desirable (it lets you keep the TTL at "1" for example). Its
usage should be addressed and left as optional for the user I suppose.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 16:43:08 -0400 (EDT)

> You don't send all traffic to all
> listener (or have another router with an active listener).

I understand that, Eric.

> This is invisible to the application btw, with the stack handling
> the reports.

I assume that the protocol somehow allows a client with no IP address
to join a multicast group, right?

> message.

Right.   So if you have a subnet with, say, 200 clients, each of which
takes on the order of ten seconds to go through the join/renew/quit
process, then you are receiving all DHCP multicast traffic on that
subnet (200*10*(lease-interval/2))/3600 seconds in every hour.   I
don't know how accurate a guess this is, but my suspicion is that it's
not far off.   Also, if any single client out of those 200 forgets to
leave the multicast group, either because it is powered off during the
renewal, hangs in the middle of the renewal (behaviour which I have
seen, BTW) or because of a bug in its stack, then that network is
going to be getting the multicast traffic until such time as the
router times out (I assume the multicast routing protocol has some
kind of timeout to take care of this).

> think of another solution that allows choice. Suggestions welcome.

Right, but this requires more configuration work than does simply
configuring a relay agent, so again, where's the payoff?

> able to bind to the stack? Am I wrong?

Maybe you're right.   Whether or not this is true, the problem still
exists - this merely reduces its magnitude.

> and he seems reasonable so maybe I'll ask him to change it <grin>.

He might even comply, but he remains unconvinced of the need to do so
at this time... :')

> Those same segments would also be getting the unicasts.

Not true.   Say you have a network with 20k DHCP clients, on average
200 per subnet.   The unicast traffic, per subnet, is then one packet
every 200*(lease-interval)/2 seconds.   The multicast traffic will be
for every client on the network, although it will be lessened by the
automatic subscription and unsubscription of subnets as clients listen
and then stop listening.

Consider the effects that this has on a DHCP server administrators'
range of choices.   Currently, as a DHCP server administrator, I can
set different lease times for different kinds of clients - clients
that roam from network to network can be configured with very short
lease times, with no significant impact on other clients.   In your
scenario, shortening the lease renewal time for a mobile client will
have a direct impact on the traffic load on every subnet to which that
client might connect.   Even if only 10% of my clients are mobile, I'm
still going to be very reluctant to provide such clients with a
shorter lease time, and as a consequence, those clients are going to
see a marked reduction in convenience.

This also opens you up to a cool denial-of-service attack: the bad guy
just subscribes to the DHCP multicast group, and suddenly your network
is flooded with DHCP traffic.   Quality of service drops, but probably
not enough to set of any alarms.   In terms of traceability, this
attack is virtually perfect - you can easily forge the packet, and
still win.   The only way to catch it is to have a really smart hub,
and even then, how easy is it going to be to seperate the DoS attack
out from all the legitimate traffic that's virtually identical?

> should be monitored for statistical purposes however.

How substantial it is will depend on the number of clients being
served by a single DHCP server.  On networks where DHCP is deployed in
a distributed manner, it shouldn't ever be a real problem.  On
networks with centralized DHCP service, which I would argue are
exactly the same networks that have the most need for easier
configurability, the impact could be dramatic.  On a corporate network
that I know a lot about, the traffic impact would be about 2% of the
realistically available bandwidth of an ethernet, and this is with
very conservative lease times.   Granted, if you go to 100mbps
networks, or have good hubs, the impact of this can be greatly
reduced, but when designing a protocol, it's very important not to
make decisions like this, because there are only so many protocols for
which you can make this sort of allowance (to wit: 50) before you run
out of bandwidth on the network.

Given that the relay agent multicast scenario I described does not
have this problem, I would argue that it's a much cleaner solution.

> (worse, the very element that I am trying to kill off).

If this is the only reason that you are proposing this protocol
change, then we don't need to continue this discussion any further.  I
presumed, based on your www resume, that you were concerned about ease
of configurability for large networks primarily, and that the relay
agent was just an aesthetic issue you didn't like.  If your sole
reason for proposing this change in the protocol is to get rid of the
relay agent, then I vote no.  I think you will find that most
implementors and knowledgable customers will vote the same way.

> usage should be addressed and left as optional for the user I suppose.

More knobs to tweak?   This is an autoconfiguration protocol.   The
fewer knobs you (the administrator) have to know about, the better.

I think leveraging multicast is a good idea, to the extent that it
reduces broadcast traffic or eases configurability, and I encourage
you to continue investigating it.  But I also encourage you to
maintain an open mind, and to not try "to kill off" a useful tool
simply because you don't like it.

			       _MelloN_

---

From: "Glenn Waters" <[email-masked]>
Date: Wed, 16 Jun 1999 17:25:54 -0400 (EDT)

does any of this multicast discussion have anything to do with the draft
listed in the subject line?

/gww

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 1999 17:26:23 -0400 (EDT)

I'm going to keep working on this, but we should probably go off-list
for any more discussion until something is in a presentable form. We've
pretty much hit on all the major issues I think. Whether anything
happens with the expiremental proposal would be left to the desires of
this group of course.

> to join a multicast group, right?

Because the delivery of multicast packets primarily happens at the
data-link layer with Ethernet (the destination address is a group
Ethernet address), recipient systems do not need an IP address in order
to receive the multicast datagrams. Therefore, a stack should not
_require_ an IP address in order to send or receive multicast packets.

Whether or not all stacks work in this way is an unknown, and will be an
interesting issue to explore during development. Naturally, just because
it shouldn't matter doesn't mean that it won't.

> subnet (200*10*(lease-interval/2))/3600 seconds in every hour.

Assuming lots of things, like that all of the clients are active for the
same ten second window. This is a stretch in my view, but is worth
monitoring. My guess is that no more than a dozen or so devices (out of
200) would be active at the same time unless there was a building wide
power failure and restart. It could be a problem if all of them were
active simultaneously.

> I assume the multicast routing protocol has some kind of timeout to
> take care of this.

Yeah. Routers will periodically issue memebership queries to the network
asking for active listeners of current gropus. If no listener responds
for the group, then traffic for that group address is no longer
forwarded to that subnet. If any one listener responds, then the group
is left as-is. Some switch vendors are doing this on a per-port basis.

> very conservative lease times.

I would be very interested in seeing how this model would consume 2% of
the available bandwidth on this network. The number of messages being
exchanged stays the same remember; the only difference is which
switch-ports get data, which really relates to per-segment utilization.
On shared Ethernet and Token Ring networks, the frame rate does not
increase at all. On switched Ethernet, the frame rate on a per-segment
basis does go up, but only for the 10 seconds or so that the client is
active. The backbone frame rate will not change. I just don't see how
this would add up to 2% except on the poorest-designed of networks.

> agent was just an aesthetic issue you didn't like.

My motivation is directly due to what I have seen at orgs when it comes
to dealing with this component. It's unnecesary, so why have it at all?
Just to preserve the status-quo?

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 1999 18:20:47 -0400 (EDT)

> does any of this multicast discussion have anything to do with the
> draft listed in the subject line?

Apologies for drifting.

I do have a concern with the option as defined, which is that it does
not provide a multi-valued array. It is feasible for a sending device
(such as a PPP server) to have multiple subnets available for clients.
Being able to seed the DHCPDISCOVER message with each of those subnets
would seem to be an important characteristic. The gateway device may
wish to get multiple OFFERS from multiple servers, each of which serve
the unique subnets, and then choose a lease (or really, choose a subnet)
for the client based on offerred data.

Is this an oversight or is this a non-issue?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 18:21:41 -0400 (EDT)

> _require_ an IP address in order to send or receive multicast packets.

How does the stack get the request to the router to join the multicast
group when it doesn't have an IP address?

> exchanged stays the same remember;

The number of messages arriving on the local network does _not_ stay
the same!  In the multicast case, whenever any client on the local
network is subscribed to the multicast group, that network sees every
request and every response for every DHCP client anywhere in the local
multicast domain.

This is _very_ different from the status quo - currently, a given
network (other than the DHCP server's network, which we needn't
consider) sees only the traffic generated by local clients, and the
traffic sent to those clients.  And since most of this traffic is
currently unicast, in a switched environment the impact will be even
smaller.  This is a *big* difference in a large corporate environment.

> power failure and restart. It could be a problem if all of them were

No, this assumes that clients are never active in the same window.  If
they are active in the same window, the problem is potentially much
less severe, because the number of windows decreases (although the
traffic within the window increases while it's open).  Operational
experience, as relayed to me from a number of large ISC DHCP users,
suggests that there is a relatively fixed steady level of traffic in a
large installation.  Whenever a subnet is subscribed to the multicast
group, it will see all of that traffic.

Actually, though, one of the scenarios we have considered in this
working group is the 9am power-on scenario, where at a company with
strict working hours, all the workers power on their DHCP client
machines at the same time.  Currently we haven't ever had a report of
a major problem as a result of this scenario, but I think with the
protocol you are proposing, we would actually have a problem.

The problem is that if every client starts up at 9am, then every
client's requests, and all the responses to those requests, will be
distributed to every the network segment in the entire company.  Now,
imagine that this company provides DHCP service from a central
location to a variety of sites, all connected via WAN links.  This
DHCP traffic is going to completely swamp any narrow WAN links.  If
this sounds far-fetched, please be aware that I know of more than one
company that has deployed DHCP service in exactly this way, and is
very satisfied with the current results.

Because of the packet loss introduced on the WAN links, this would
cause a large percentage of the clients not to hear responses to their
requests, resulting in retries.  Since different packets will be lost
on each WAN link funnel, the chances that a particular client's
response will make it back to its own site are fairly slim, although
its response will almost certainly make it to *some* site.

The packet storm would probably subside fairly quickly, but in the
aftermath, a large percentage of all the Win2010 machines in the
company would have autoconfigured, and would be unable to use the
network.  The result of this would be a support call storm the likes
of which I shudder to imagine.

While I do not personally know of a company where the 9am scenario and
the WAN scenario both currently exist, it is easy to imagine that such
a company exists, and I think it's worth being careful not to break
their network.  I suspect most DHCP client vendors will feel
similarly: these people have deep pockets, will be buying a lot of
Win2010 licenses, and will not be interested in hearing explanations
as to why their network melts down and their support phones ring off
the hook every morning at 9am.   They will be interested in
eliminating whatever software caused the problem.   Given that I like
seeing my software widely deployed, I'm going to think long and hard
before implementing support for the protocol you're suggesting, and I
suspect other DHCP client vendors will as well.

> I just don't see how this would add up to 2% except on the
> poorest-designed of networks.

The corporate network to which I am referring above has a steady-state
inter-packet arrival gap at the DHCP server of 100ms.  If you figure
that the headroom on a shared ethernet segment is about 25% of the
total bandwidth, or 2.5mbps, and the average DHCP packet is 576 bytes,
and that the DHCP server doesn't ever respond to any DHCP packet, then
the bandwidth consumption works out to around 1.7%.  If you figure the
DHCP server responds to 100% of the packets it receives, the bandwidth
consumption is actually 3.4%.  I chose 2% as a nice round number.  Of
course, if you go to 100mbps full duplex, these numbers drop by more
than an order of magnitude, and if the deployment horizon for this
protocol is ten years, maybe that's not a bad assumption to make.

> Just to preserve the status-quo?

You claim that it is unnecessary, but you haven't said anything so far
that backs up this claim, other to propose a protocol that I would be
very reluctant to deploy.  I claim that it is quite necessary, and I
think I've made a pretty good case that that's so.  Furthermore, I've
provided you with an easily-implemented way to get rid of the
configuration problem that you're complaining about, without
introducing any of the problems your protocol would introduce.  So no,
I'm not arguing to preserve the status quo.  I'm arguing in favor of
the best protocol we can come up with that solves the problems we need
to solve.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 18:59:18 -0400 (EDT)

I think Mr. Hall was proposing that the subnet selection option be
used by the DHCP client to indicate its location.   The subsequent
discussion has strayed a bit from the original topic, but I still
think it's useful.

			       _MelloN_

---

From: "Glenn Waters" <[email-masked]>
Date: Wed, 16 Jun 1999 20:16:15 -0400 (EDT)

the intent is that the device (the PPP server in your example) would get an
address on each of the subnets using separate DHCPDISCOVERs for each subnet.
the device would then cache those addresses and hand them out as it sees
fit.

i'm not sure how useful it is for a device getting multiple offers
**potentially** from different subnets -- i would think that you want to
specify precisely the subnet on which you want the address.

/gww

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eric A. Hall
> Sent: Wednesday, June 16, 1999 18:21
> Subject: Re: draft on the "Subnet Selection Option for DHCP"
>
>
>

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 1999 21:39:07 -0400 (EDT)

> the device would then cache those addresses and hand them out as it
> sees fit.

Is caching lease data a good idea? Is this really the intended use? I'm
asking out of curiosity. It would seem to me that requesting leases on
an as-needed basis would be safer, at least from expiration or conflict
avoidance points of view.

> **potentially** from different subnets -- i would think that you want
> to specify precisely the subnet on which you want the address.

I guess my concern is that in some scenarios the gateway device is not
entirely sure which subnet it should be making assignments from and
needs clues from the network to make the decision.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Jun 1999 23:38:36 -0400 (EDT)

> for the client based on offerred data.

The draft specifies that the server will treat the network address
provided in the subnet selection option the same way that it currently
treats the giaddr field.   Current DHCP servers can be configured to
know that a giaddr on one subnet actually refers to a network segment
containing more than one subnet, and can therefore assign addresses on
any such subnet.

We talked about adding the functionality you're proposing in
Minneapolis, but wound up deciding it wasn't a good idea.  The
consensus was that since the DHCP server needs to know the subnet
configuration in order to do address assignment, having the relay
agent or RAS send a selection of subnets on which to assign an address
adds no value, and indeed needlessly complicates the implementation of
the DHCP server and the configuration of the relay or RAS agent.

			       _MelloN_

---

From: "Glenn Waters" <[email-masked]>
Date: Thu, 17 Jun 1999 10:07:09 -0400 (EDT)

> avoidance points of view.

correct, caching is not necessary -- it is a design decision.  the device
must remember the allocated addresses and perform renews on those addresses
as required by the DHCP protocol definition.

> needs clues from the network to make the decision.

the device must know which subnets it wants the addresses for.  what it may
not know is whether there is more than one subnet address for the network
segment.  but that's ok -- when required, the dhcp server will be configured
with that information.

/gww

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 17 Jun 1999 11:48:52 -0400 (EDT)

>specify precisely the subnet on which you want the address.

	I completely agree.  The case Eric discusses is where
	each server manages only one of the subnets in the multiple
	subnet list, but what if one server manages 2 or more of the
	subnets specified in the list.  From which subnet does it return
	an offer?  The first?  The one with the most addresses?

	How about: if you want offers for different subnets, you
	send out different discovers with different subnet selection
	options in them.  Thus the simple case remains simple, and
	the extra complexity burden is borne by the client that needs
	the extra capability.  

	Just because we know of no such clients today doesn't 
	mean that we shouldn't allow them to operate, 
	but it *does* mean that we shouldn't burden the 
	draft/RFC with complexity to optimize their
	operation.  The approach outlined above will work
	fine for these clients should they ever exist.

	Cheers -- Kim

---

From: Rob Stevens <[email-masked]>
Date: Thu, 17 Jun 1999 13:29:09 -0400 (EDT)

>effective when I'm trying to eliminate another secondary service.

I was under the impression that the ICMP "Subnet Query Message"
was obsolete.

I realise though that what you may be suggesting is that it should be
resurrected.
(2010 seems about right).