Subject: DHCP with multicasting relay agents...

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

> I guess I missed the description on what function the proxy would
> provide in the multicast arena. Please clarify the exact functionality?
> Would it listen for multicast queries and then forward them as unicasts
> to the targets?

The function it would provide would be that you'd have a relay agent
in each router, just like you do now, but instead of having to
configure each relay agent with a list of DHCP servers to which to
forward packets, you would simply have the relay agent forward all
client DHCP packets to a well-known, routed multicast address.   The
protocol would otherwise be unchanged - the relay agent would still
stuff giaddr, and the server would still unicast the response to the
relay agent, which would either broadcast or unicast it to the client
on the local network.

Just this one change could eliminate the relay agent configuration
problem, which I think is the real problem you're trying to solve.
It also has the benefit that it requires no change to the DHCP client
- just to the DHCP relay agents and the server, which are orders of
magnitude easier to change, and whose vendors would have a much
greater motivation to implement the new protocol.

If you want to also eliminate the current problem of broadcast traffic
originating from the client, you can do this by having new clients use
multicast to a well-known subnet-local multicast address on which
relay agents all listen.  You still have a relay agent on the local
network, but now all the other DHCP clients on the network don't have
to hear new-style clients' initial startup messages.   Compared to the
relay agent configuration problem, though, this is a fairly minor
issue.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 17 Jun 1999 01:34:13 -0400 (EDT)

> client DHCP packets to a well-known, routed multicast address.

This is as an acceptable solution to the primary issue of mandatory
proxies if it means getting done quickly. While it does not offer all of
the functionality that an all-multicast approach would offer, it
certainly doesn't have anywhere near the quantity of problems either.

Later, when emboldened with some kind of success, perhaps we can go back
to tackling the DHCP-Client multicast group problems.

> problem, which I think is the real problem you're trying to solve.

It is my primary objective, but I also liked the opportunity of making
n-way replication easier as well. This approach does not address that
directly, although it does offer a channel for widely distributing data
easily, which could be useful as a building block.

I suppose the logical path would be to pursue the DHCP-Server group
functionality and leave the client issues for later.

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Jun 1999 02:45:39 -0400 (EDT)

> to tackling the DHCP-Client multicast group problems.

That sounds like an excellent approach.

> easily, which could be useful as a building block.

Right.   You could indeed use the same multicast infrastructure that
the relay agents would use to allow servers to do multicast
propogation of lease updates for some future n-way replication
protocol.

> functionality and leave the client issues for later.

Sounds like a plan!   When can we expect to see the draft?   *evil grin*

			       _MelloN_

---

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

> Sounds like a plan!   When can we expect to see the draft?

Since the proposed mechanism is very constrained and therefore very
simple, there isn't a lot that needs to be done. Essentially, the
proposal boils down to:

  * Forwarders SHOULD be configurable to relay requests to the
    multicast group address of X.X.X.X.

  * Servers SHOULD be configurable to listen for requests on the
    multicast group address of X.X.X.X.

With Ted's prooposal, nothing else changes anywhere in the spec.

I'm wondering if instead of writing a new spec we could just modify the
existing DHCP spec? These two changes would be optional, and would not
require changes to any existing implementations.

The cumulative amount of text would be fairly small, maybe along the
lines of six paragraphs altogether.

---

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

> I think it's worth specifying this is a seperate draft, so as to not
> confuse the progression of the existing draft, and also so as to
> highlight the fact that this is new functionality.

Okay.

> I think your six paragraph estimate is a tad low, but not by more
> than a factor of two or so 

Given the room a separate document affords, you are probably right.
There isn't a whole lot of stuff here though. The only details are
things like "relay agent SHOULD NOT join the multicast group (only send
to it)" and some TTL issues.

> if you don't have time to write the draft, somebody else here
> probably can. I may have some free time to do this and some other
> small drafts that need to be written up soon... :')

I don't mind writing it, but I wouldn't mind NOT writing it either.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Jun 1999 16:02:27 -0400 (EDT)

I think it's worth specifying this is a seperate draft, so as to not
confuse the progression of the existing draft, and also so as to
highlight the fact that this is new functionality.   I think your six
paragraph estimate is a tad low, but not by more than a factor of two
or so - remember that when I first tried to explain to you what I had
in mind, you thought I meant something else, and we need to
communicate to readers who have much less of a history with IP
networking than you do.

It shouldn't be very hard to get a draft like this through, though
(although maybe Thomas can comment on that further).  I believe there
is a boilerplate for writing these drafts now, so it shouldn't be too
hard.  However, fundamentally I was just tweaking you - if you don't
have time to write the draft, somebody else here probably can.   I may
have some free time to do this and some other small drafts that need
to be written up soon... :')

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Sun, 20 Jun 1999 21:49:05 -0400 (EDT)

>relay agent, which would either broadcast or unicast it to the client

Using multi-cast in this way is, in fact, exactly how DHCPv6 works.
DHCPv6, in fact, specifies *only* the use of multicast by relay agents for
forwarding DHCP messages; there is no mention of configured unicast direct
to DHCP servers.

You raise an interesting point that is not currently discussed in the
DHCPv6 draft - the relay agents should transmit to (but not join) the DHCP
servers multicast address.

Changing contexts back to DHCPv4, I'm not sure that using multicast would
in any way change the protocol, per se.  My first thought was that the
multicast mechanism might only require a short informational RFC.  After
thinking a little harder, seems like we ought to get an address from IANA
and then write a standards track RFC documenting the use of that address
and any specific details.

Does anyone have operational experience with the use of multicast by relay
agents?

We did originally consider the use of multicast in DHCPv4 but decided
against it because it was not widely deployed or available when we
originally decvised the protocol.  

- Ralph

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 21 Jun 1999 04:48:59 -0400 (EDT)

> Changing contexts back to DHCPv4, I'm not sure that using multicast
> would in any way change the protocol, per se.

It wouldn't.

> After thinking a little harder, seems like we ought to get an address
> from IANA and then write a standards track RFC documenting the use of
> that address and any specific details.

I asked IANA for a Class D address last week, and am writing a draft
that Ted will implement based on our conversations. If it works (and it
should) we'll turn it over for further process. If this is bad form
somebody let me know.

I don't see any reason it can't go into the main proto, unless there are
timing concerns or other issues outside of the proto itself.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jun 1999 07:39:10 -0400 (EDT)

>should) we'll turn it over for further process. If this is bad form

Sounds like good form to me.  Thanks for taking the initiative to formalize
the multicast mechanism.

>timing concerns or other issues outside of the proto itself.

Eventually, the use of multicast should be documented in the main protocol
spec.  Until we republish the spec as a new RFC - which probably won't
happen until the spec goes to Full Standard - it would be best to publish
the multicast doc as a separate RFC.

- Ralph

---

From: Erik Guttman <[email-masked]>
Date: Mon, 21 Jun 1999 08:52:44 -0400 (EDT)

> should) we'll turn it over for further process. If this is bad form

Eric, 

Is a global multicast address really what we want?  I would think that
an administratively scoped multicast address would be more appropriate.
There are two possibilities here:  One is to require the use of MADCAP
to allocate and discover the multicast address dynamicly.  The other,
probably more desirable, is to request an assignment of a fixed multicast
address from IANA in the administrative multicast range.  RFC 2365:

9. Structure and Use of a Scoped Region

   The high order /24 in every scoped region is reserved for relative
   assignments. A relative assignment is an integer offset from highest
   address in the scope and represents a 32-bit address (for IPv4). For
   example, in the Local Scope defined above, 239.255.255.0/24 is
   reserved for relative allocations. The de-facto relative assignment
   "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
   SAP [SAP]. The next relative assignment, "1", corresponds to the
   address 239.255.255.254 in the Local Scope. The rest of a scoped
   region below the reserved /24 is available for dynamic assignment
   (presumably by an address allocation protocol).

There are only 255 such relative address assignments available, and
only for fundamental discovery/configuration protocols - which clearly
describes DHCP.

The process is to make an application to IANA for one of these protocols
carefully describing that it is to be a "relative assignment for use
with administrative scoped multicast addresses" & cite RFC 2365, section 9.

The reason you *don't* want a global multicast address is there is no
case I can imagine where you'd want these messages being routed outside
of the periphery of an administered network, ie. into the global Internet.

Erik

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Jun 1999 09:33:36 -0400 (EDT)

Excellent.   I thought there was a way to do this.   This solves the
TTL problem quite nicely.

			       _MelloN_

---

From: Nathan Lane <[email-masked]>
Date: Mon, 21 Jun 1999 18:44:50 -0400 (EDT)

> require changes to any existing implementations.
[Nathan Lane]  Sounds good...but we don't have a multicast infrastructure.  I have a pretty simple solution to at least the discover part of the protocol - all my boot servers for networks that need relay agents are on a single segment and the relay agents are configured to send the DHCPDISCOVERS/bootp requests to the broadcast address on that segment.  It doesn't solve all the problems but it covers 99% of all outage cases at our sites: DHCP server dead or unresponsive.

If I had a multicast infrastructure, that'd be even better from an agent configuration perspective.
	-Nathan Lane
	Senior Network Engineer
	Wal-Mart Stores, Inc.
	(501) 277-5786

---

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

> > I asked IANA for a Class D address last week

> only for fundamental discovery/configuration protocols - which clearly

Looking at IANA's list of currently defined administratively scoped
addresses shows the following:

   Relative  Description                                  Reference
   --------- -------------------------------------------- ---------
       1     MDHCP Protocol                               [Patel]
 
Apparently a DHCP group address is already there. I'm assuming this is
the v6 group address. I wonder if we can share this group address, and
what the ramifications would be from a protocol perspective. Any
thoughts from anybody who knows?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jun 1999 14:50:51 -0400 (EDT)

> thoughts from anybody who knows?

No, this is the Multicast Allocation group, which was formerly known
as MDHCP.   It actually has nothing to do with DHCP.   We'll need
address number 2, I guess.   :')

			       _MelloN_

---

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

I resubmitted the request, explicitly asking for a relative address. I
also asked that IANA update the existing MDHCP entry to be MADCAP.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Jun 1999 14:50:20 -0400 (EDT)

>   Relative  Description                                  Reference

This address was allocated for a (now defunct) proposal for a service to
allocate multicast addresses via DHCP or a DHCP-like protocol.  It has
nothing to do with either DHCPv4 or DHCPv6.  We'll need a different
administratively scoped address for DHCP relay agents.

- Ralph

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 23 Jun 1999 15:17:48 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
--------------------------------------------------------------------
Since we have been discussing the possible use of multicast with DHCPv4,
I decided to look at the DHCPv6 draft to see how it uses multicast. It
seems that a significant amount of time was devoted to this particular
issue during the design of DHCPv6. We should take advantage of this
effort. Here's what I found:

* All-DHCP-Agents (a reserved link-local multicast address listed in
  the spec) is used for sending messages from clients to relays.

* All-DHCP-Servers (a reserved site-local multicast address listed in
  the spec) is used for sending messages from relays to servers.

* A server may tell a client to listen to a multicast address for
  reconfigure messages. In this case, the multicast address is
  apparently chosen by the server and may have any scope.

* A site-local multicast address named All-DHCP-Relays is defined, but
  I can't find anywhere that it's used.

I welcome corrections or clarifications from any of the DHCPv6
developers.

The proposal we have been considering corresponds to the use of the
All-DHCP-Servers address. This raises one question that I had been
considering:

If we use a scope-relative multicast address for this purpose, which
scope should a relay use? IPv4 Local Scope? A subrange of Organization
Local Scope? It seems that this would have to be another configuration
parameter. IPv4 Local Scope would be a reasonable default for this
parameter, since this scope must always exist whenever IPv4
administrative scoping is in effect.

When administrative scoping is in effect, packets sent to an
administratively scoped address should have an initial TTL of 255.
However, if administrative scoping is not in effect, such packets may
leak out of the organization. Therefore, I would suggest that this
multicast feature be turned off by default.

Just a few ideas. Comments welcome.

-Steve

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 23 Jun 1999 15:18:11 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
--------------------------------------------------------------------
>    Relative  Description                                  Reference

This assignment should be updated to say "MADCAP Protocol." MADCAP is a
client-server protocol used for dynamically allocating multicast
addresses. Its design was originally based on DHCP and its name was
originally MDHCP. There are still a few resemblances, but it is
certainly not compatible.

The MADCAP spec has been submitted to the IESG for publication as a
Proposed Standard. The latest version is draft-ietf-malloc-madcap-05.txt

I haven't been following this discussion, but I would strongly suggest
not using the same scope-relative address as MADCAP.

Thanks,

Steve Hanna

---

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

I'll respond to two points that you raise, Steve.  First, with respect
to DHCPv6 specifically: I think it would be a mistake to try to
shoehorn the DHCPv6 effort back into IPv4.  The goal here is to come
up with a simple change to the DHCPv4 protocol that doesn't affect
clients at all, and that can be rapidly deployed to good effect.

What we have proposed is a very simple extension to the existing
protocol whose sole purpose is to eliminate the need to configure DHCP
relay agents with the IP addresses of DHCP servers.   Instead, the
DHCP relay agent simply multicasts any packets it receives from
clients to a well-known multicast address on which all servers
listen.   The server unicasts its response to the relay agent, which
unicasts or broadcasts its response to the client, as the client
requested.

When you folks were designing DHCPv6, you had one major luxury that we
DHCPv4 people don't have - you don't have a large installed base of
clients.  So you could change the behaviour of the client quite
dramatically, and it was okay, because you were changing the behaviour
of a client whose widespread deployment was still in the future.

The change that we are proposing to the DHCPv4 protocol to support
relay agent multicast does not preclude future DHCPv4 enhancements
along the lines you suggest.   However, if we try to shoehorn those
enhancements into the current proposal, the result will be that the
current proposal will not be useful in the short term.

> multicast feature be turned off by default.

How can packets multicast to an administratively scoped multicast
address leak out of one organization and into another?   I think the
only way this can happen is that the administrators of both
organizations have to have misconfigured their border routers - it is
not sufficient for just one organization to have done this, because
even if the multicasts make it across their border router, some other
border router has to be interested in forwarding the multicasts
inward.   So I think this is a non-problem.   I am, however, very
interested in what the DHCPv6 people have to say about this particular
issue.

			       _MelloN_

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Thu, 24 Jun 1999 11:47:32 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
---------------------------------------------------------------

			       _MelloN_

---

From: Steve Hanna <[email-masked]>
Date: Thu, 24 Jun 1999 13:06:31 -0400 (EDT)

> clients at all, and that can be rapidly deployed to good effect.

I agree with you on this. I wasn't proposing that DHCPv4 adopt all of
the multicast features of DHCPv6. I was just describing them.

The extension to DHCPv4 that you have proposed seems very similar to the
use of the All-DHCP-Servers address in DHCPv6. Relays forward packets to
this address for delivery to all DHCP servers within a particular
domain.

However, DHCPv6 has a single well-known multicast address for this
purpose, whereas you have proposed using a scope-relative multicast
address. This address will appear separately in each scope that a relay
is in: IPv4 Local Scope, Organization Local Scope, etc. So my first
question was: which scope should the relay use? I suggested IPv4 Local
Scope as a reasonable choice, since it will always be around. However,
it would probably be good to make this a configurable parameter.

> > However, if administrative scoping is not in effect, such packets
> > may leak out of the organization. Therefore, I would suggest that
> > this multicast feature be turned off by default.
> 

Administrative scoping is put into effect by configuring routers so that
they don't forward packets sent to an administratively scoped multicast
address outside of the intended administrative scope. If nobody has done
this configuration at a particular site, nothing will prevent packets
sent to an administratively scoped multicast address from that site from
being forwarded out of the site.

Effectively, the community of people who haven't configured their
routers to enable administrative scoping forms a single scope. Traffic
sent to administratively scoped addresses will be forwarded to group
members throughout that community so long as the TTL is greater than
zero.

Since most sites have not enabled administrative scoping, we should
definitely consider this when designing our protocols. That's why I
suggested that the multicast feature be turned off by default.
Otherwise, naive admins will end up with a system that forwards messages
from their relay agents to DHCP servers around the world. And they'll be
very confused when their users get address assignments from somebody
else's DHCP server (or vice versa).

I don't know if this is an issue for DHCPv6 or not. Perhaps the
site-local addresses they're using will always be constrained properly.

Thanks,

Steve

P.S. I wasn't involved in the development of DHCPv6. It looks very nice,
but I can't take any credit for it.