Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D

From: Bernie Volz <[email-masked]>
Date: Wed, 2 Feb 2000 09:20:42 -0400

Ted:

>> My areas of clarification are mostly around the server automatically
>> creating a scope; but this may be considered a server issue and thus may
>> be outside the scope of the draft/RFC.
>
>This is precisely the problem, Bernie - specifying server behaviour
>does appear to be beyond the scope of the relay agent information
>options draft, but this option does imply behaviour on the part of the
>server, and to leave it unspecified is inappropriate.   To leave it
>unspecified will likely cause major trouble in the future.

I believe from a PROTOCOL standpoint, the document is clear. My issues
are CONFIGURATION related. Creating a scope can be done manually or
automatically. If done automatically, how are the ranges of addresses to
be used determined, what options are associated with the scope, etc.
This is all a configuration issue and we generally stay away from that
in these documents. I don't see why we would want to constrain
implementations to do what they feel is appropriate for their needs
(whatever they may be).

Basically, using ISC configuration like syntax, one might have:
	template subnet 255.255.192.0 {
		range 2 1022;
		option routers 1;
	}

This would say when creating a subnet, declare a range of .2 to 3.254
(this is a template for a 22 bit mask) with a router at the .1 address.

But, again, I don't see that the draft needs to specify this. Whatever
it means to your server to create an appropriate scope is what should be
done. The draft says that servers MAY (not SHOULD or MUST) do this.

Perhaps if you are clear as to what issues you feel aren't addressed in
the draft I can better understand your concerns. Your original message
was exceedingly vague in my opinion. What are the "wider implications"?
Why do you suspect that it is likely to result in "multiple non-
interoperable implementations"? I could make these statements about
anything that is proposed - back them up with concrete issues please! I
agrue that the generic concept of creating a scope is clear; what isn't
clear and is a server configuration issue is what in detail a server
does when creating a scope (see above).

>> I can certainly live without the option being in the draft. Though, I
>> don't have servere objections if it is left in. While I easily agree
>> with Ted that more description or discussion on its intended usage and
>> issues regarding it could be added, I feel what is there is clear. 
>
>Can you please boil this down to one of "yes, I want the draft left as
>is," "I abstain," or "no, I want the draft changed?"   :'}

How about a fourth choice - "I don't care". Perhaps you would call that
"I abstain".

>Thanks!
>			       _MelloN_

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Feb 2000 12:50:56 -0500

> I believe from a PROTOCOL standpoint, the document is clear.

>From the standpoint of the protocol by which the relay agent
communicates to the DHCP server the subnet mask that it is using on
the subnet to which the client is connected, I agree that this is so.

However, this is not the entirety of the protocol.  The point of a
good protocol specification is that two practitioners in the field
should both feel confident that they can say what the other's code
will do, without ever having done an interoperability test, as long as
both practitioners know that each other's code conforms to the
standard.  This is a high standard to shoot for, and maybe we can't
perfectly reach it, but we should at least try.

What I am saying is that by addressing strictly the wire format of an
option, the subnet mask suboption specification doesn't try to achieve
this goal, and this is why I want to discuss it further.  My purpose
in not participating in consensus here is not to perfect the
specification of the subnet mask suboption right now.  It's simply to
recommend that we discuss it further, and try to specify it more
completely.

The reason that I give the parameter request list as an example is
that the *format* of the parameter request list is perfectly described
in RFC2132, but the *implications* of the parameter request list are
not.  I believe the subnet mask suboption has this same problem.

I will mention a few places where I see problems with this suboption,
but again, the purpose of this discussion is to pull the suboption out
into its own draft and *then* nail it down properly, *not* to nail it
down properly right now, so please do not argue the points I present
below with me right now - just take them as examples of why the subnet
mask suboption ought to be discussed further.

First, what *else* is in the packet the router sends that interacts
with this suboption?  The giaddr comes to mind.   What should the
giaddr be?   Should it be specified?   Should the giaddr be one
greater than the subnet number for the subnet, for example?   Are any
IP addresses on one of these subnets reserved?   Is the .0 reserved?
Is the .all-ones reserved?   What about .0+1 and .all-ones-1?   What
does the server do if the router sends a subnet mask of /30, /31 or
/32?

What is the purpose of this suboption?   Is it so that routers can
dynamically add subnets, or just so that routers can inform the DHCP
server as to their configuration, so that the DHCP server can confirm
that it's configured correctly?   Or so that the DHCP server can
implicitly be configured by configuring the router - i.e., to push
configuration information away from the server and out to the router?

What are the implications if there are two DHCP servers doing
failover?   Both DHCP servers had better make the same assumptions,
right?   Do the servers do failover on the new subnet?   What if there
are two DHCP servers that *aren't* doing failover?

What happens if somebody sends the DHCP server a forged packet with a
giaddr of, say, 16.0 and a subnet mask of, say, 255.0?   The ISC DHCP
server currently preallocates memory for leases, assuming that it's
better to crash on startup due to a lack of memory than to crash
later.   So it's going to allocate ~2^24 leases when it receives this
packet.   This is an instant denial of service attack.   Should I go
to lazy allocation of leases?   Should there be a recommendation in
the draft about this?   A security considerations notice?

What happens if there are redundant routers serving the subnet?   What
routers option does the DHCP server send?   Does it track the IP
addresses of routers from which it's received this option, and notice
if two have IP addresses on the same subnet?   What if it's already
given one of these addresses out?

What happens if two routers send conflicting information - one saying,
for example, that 10.0.0.0 is a /24, while the other says it's a /16?

How are dynamically-allocated subnets garbage collected?   Are they?

Yes, many of these points are operational concerns, but operations is
part of the protocol.   If the protocol specification doesn't address
these issues, I can see that for many of these issues, there is the
potential that one implementor will address the issue one way, and
another implementor will address the issue another, and that the ways
in which these issues are addressed will be sufficiently different
that they will create interoperability problems.

This is why I want to see a seperate draft for this option.   I'd like
to see these points addressed in the draft, or at least have a
discussion about them before the suboption becomes a standard.

			       _MelloN_