Subject: [dhcwg] draft-ietf-dhc-server-override-03.txt returned to dhc WG for review (2nd call for review)

From: Ralph Droms <[email-masked]>
Date: Tue, 07 Mar 2006 07:18:05 -0500

WG members and draft authors - One issue with this draft that we need to
address in WG discussion is the problem of hiding whether a DHCP message
received by a server from a client was initially broadcast or unicast.
David Hankins originally raised this issue in
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05599.html, and again
in http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05891.html

Is there agreement that David's analysis is correct?

Does the problem need to be fixed?

How do we go about fixing it?

- Ralph
=====original message
The IESG has voted on draft-ietf-dhc-server-override-03.txt, and there are
insufficient votes to accept the I-D for publication at this time.
According to IESG rules, with 5 abstentions the I-D is returned to the WG
for further review and revision.

You can read the IESG's votes, comments and reasons for abstentions at
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ball
ot_id=1911&filename=draft-ietf-dhc-server-override

In the IESG comments, Allison Mankin mentions a "pretty devastating comment
on this draft", which is David Hankins' e-mail from last November:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05599.html

In reference to other comments in the IESG record about the process
surrounding this draft, there was a WG last call on the draft last February,
and comments rraised during the last call were addressed by the authors in
the current (-03) revision.  David's e-mail was posted shortly after the
publication of the -03 revision.  There was also an IETF last call on the
draft, during which there was no further comment.

While the WG needs to address David's comments, in other respects the WG has
followed appropriate process and has been involved in the development of
this specification.  We'll start with a discussion on the WG mailing list
about the IESG comments and develop consensus about what revisions might be
necessary to address those comments.

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 9 Mar 2006 11:38:34 -0800

> http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05599.html, and again

To be fair, there may not have been mailing list discussion upon that
because IETF 64 was going on.  I do recall speaking with someone about
this over cookies in the lobby, but I think he and I may have came away
from that conversation with two radically different impressions (he may
have thought he convinced me I was wrong, I thought I convinced him we
needed to have a discourse about it to make sure we've bent brains to
think about it).

> Is there agreement that David's analysis is correct?

Obviously I tend to think so, but I'm also fairly biased.

Let me re-characterize my first complaint ("muddies giaddr") now that
I've had time to think about it a third time through;

In RFC2131 section 3.2, we first see text that advises that a server may
reasonably respond with a NAK only in the event that the client broadcast
its query (context from the paragraphs above), or giaddr is set (indicating
that the client broadcast its query, we are told).

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server.  The server MUST
      broadcast the DHCPNAK message to the 0xffffffff broadcast address
      because the client may not have a correct network address or subnet
      mask, and the client may not be answering ARP requests.
      Otherwise, the server MUST send the DHCPNAK message to the IP
      address of the BOOTP relay agent, as recorded in 'giaddr'.  The
      relay agent will, in turn, forward the message directly to the
      client's hardware address, so that the DHCPNAK can be delivered even
      if the client has moved to a new network.

And again in 4.1.

   If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
   field is zero and the 'ciaddr' field is nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

It's really hard to interpret that last sentence in more than one
way.

And again in 4.3.2.

      If 'giaddr' is set in the DHCPREQUEST message, the client is on a
      different subnet.  The server MUST set the broadcast bit in the
      DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
      client, because the client may not have a correct network address
      or subnet mask, and the client may not be answering ARP requests.

Which slightly contradicts 3.2 quoted above (relays will never unicast
if you always set the broadcast bit).

So, I conclude that servers are not allowed, by rfc2131, to respond to
unicast REQUESTS with DHCPNAK, even if they are able to broadcast the
NAK to a locally connected network.  They may unicast to relays, which
we take to mean that the client request was broadcast (wether the relay
knows to broadcast or link-layer-unicast the response to the client or
not, 3.2 seems to waffle on this).  Further, we use giaddr as a hint as
to wether or not the client packet was unicast.

The message is clear to me, in the above text snippets:  DHCPNAK while
the client is perceptively in RENEWING state is illegal (despite its
presence on the state engine in 4.4, this process is never codified in
text).

Adopting this option creates an avenue where that can no longer be
sensed by the server, and is not being enforced by the relay.

This particular issue (DHCPNAK'ing unicast REQUESTs) is the only place
I can see that affecting our server implementation (due largely to a
grep -r of our sources...incredibly scientific audit, yes I know).

So one open question from me is:  Can anyone think of any other ways
that losing the server's ability to sense remote broadcast vs unicast
may be harmful?

At any rate, my standpoint on this is that a reference implementation
(tm) can not state itself to be so if it implements both RFC2131 and
this new draft.  They are contradictory.

As a consequence, ISC DHCP will likely not be able to implement this
option (I think rfc2131 is more important to implement to reference).
That may or may not have any bearing on wether this is important
enough to fix, I guess I'm a biased judge of that too.

As to how to fix this, there are a variety of methods.  Updating
RFC2131 to allow servers to unicast NAKs to clients in RENEWING state
seems at first blush the most appropriate, if least expedient.  I
tend to think that the servers were not allowed to respond to
unicast REQUESTs with NAKs probably on some combination of the
grounds that the client's lease was still valid at that time...the
server has made a 'promise' and can't reneg...and we don't expect
to hear from clients that are unicasting REQUESTs in their RENEWAL
state and are on the wrong network: you shouldn't be able to reach
your default gateway (you can't arp for it, and the link layer
address will be different).  And yet, we do see this happen in the
wild (I explained how in the very first message I sent on this topic
last Nov: 802.1q, but see also rfc1918).  Giving up on the former,
trusting servers to keep their promises even if they emit NAKs, and
embracing the latter is probably worthy (and commonly done in the
field by sysadmins with crafted configuration syntax anyway).

Modifying the current draft so that relays either drop NAKs when
the clients are perceivably in RENEWING state (requires state on
the relay), or producing a new field to inform servers of wether
the client's packet received was unicast or broadcast, seem like
two other workable ways to go about it, with varying degrees of
'blech' factor.  Really, the latter, throwing in an 8-bit field of
'flags' and assigning "client packet was broadcast or unicast" to
one of them seems pretty reasonable.

It seems also like the most cautious thing the draft could do is to
advise relay implementors not to forward unicast REQUESTs if the
client is not directly attached to the appropriate network (and yet
it is somehow able to receive them anyway, either due to contrivance
of configuration (identical mac address) or the means in which they
are collected (berkeley sockets)).  Specifically because of the way
giaddr clouds the server's judgement in this matter.

I do think no action on this is shortsighted.

I think my objections on LBA grounds are reasonably well stated that
I don't need to further qualify them.

I believe it to be worth fixing because I believe LBA serves a useful
purpose.

But I really have no idea how to fix it without putting state on the
relay, or producing another option that relays can ask clients to
store and include when they renew (requiring client adoption - or
at least client adoption to support LBA).  "Your 'other' server
identifier?"

Perhaps a relay agent option the server can fill that includes the
LBA hash field and all known participating servers' configured
ranges within that field (so the relay implements LBA instead)?

I think the draft should at least reference the RFC on the LBA and
describe the problem, if not atempt to solve it.  "Places where this
option may not be applicable" is just as important to document as
applicability, if not moreso.

One final question:  Has anyone thought about the fact that this
adds a new behaviour for clients to deal with?  Prior to this, unicast
RENEWAL would get at most one response from one server...now it may
get two differing responses from what appears to it to be one server
but are in fact two.

I appreciate that the behaviour described in this draft is 'just like
dhcpv6' and we all (yes, me too) like dhcpv6.  But dhcpv4 itself is
not like dhcpv6.  We're using a phillips here to drive a standard slot
screw (or at least, we are in danger of doing that if we don't look
very closely to compare the two).

-- 
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: Stig Venaas <[email-masked]>
Date: Tue, 14 Mar 2006 16:32:54 +0100

> Obviously I tend to think so, but I'm also fairly biased.

I've been trying to understand all the details of what's going on, and 
possible issues. Many of you know the spec better than me though, so 
please bare with me and let me know if my observations are wrong.

> presence on the state engine in 4.4, this process is never codified in

I believe illegal is too strong. I would say that it doesn't say that 
DHCPNAK should be sent in response to RENEWALs. Also, if DHCPNAKs were 
sent, they would be broadcast to 0xffffffff which doesn't make sense if 
client and server are on different networks. My understanding is that 
the intention is that DHCPNAKs should not be sent in response to RENEWALs.

Using server override, a RENEWAL would be unicasted to relay which sets 
giaddr. My first question then, is how does relay know which server to 
send the message to (if relay is configured with multiple servers).

With server override, the behaviour for RENEWALs is changed. Server will 
when receiving this message attempt to verify the client's address 
(since giaddr is non-zero). AFAICT this will always succeed, since 
client uses the relay from which it initially got the address. Since 
this succeeds, no DHCPNAK will be sent. Are there cases where the client 
is in RENEWAL state, where the server now would respond with DHCPNAK to 
the renewal?

> grep -r of our sources...incredibly scientific audit, yes I know).

So, as I wrote in my last paragraph above, I'm not so sure there would 
be any DHCPNAK's to a request from a client in RENEWAL state anyway.

> that losing the server's ability to sense remote broadcast vs unicast

Good question.

> this new draft.  They are contradictory.

I don't see it this way.

> I do think no action on this is shortsighted.

Right, so I agree that it makes sense for the relay to check that client 
address is valid for unicast messages. This would be an improvement over 
the current situation where a server gets the unicasted message 
directly, and is not able to verify it.
> applicability, if not moreso.

I agree there is a problem when the relay is configured with multiple 
servers.

Stig

> ------------------------------------------------------------------------
>

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 14 Mar 2006 12:56:21 -0500

Stig, David,

I'm responding to Stig's response to David's message, but didn't
include the considerable text to (hopefully) enhance clarity.

I will discuss the problems that David discusses, and at the end,
I will propose a different approach to solving them which also
solves additional related problems.

I hear three issues:

  1.  A DHCP server can't tell if a DHCP renewal was broadcast or
  unicast by examing the giaddr if all renewals are unicast to
  the relay agent and then unicast on to the DHCP server with a
  giaddr inserted.

  2.  In a load balancing situation both servers will get all
  renewals.

  3.  In a load balancing situation a client will get two Ack's,
  instead of one as is the usual case.

In detail:

Issue #1:  Server can't tell broadcast from unicast.

        David says:

>        The message is clear to me, in the above text snippets:
>        DHCPNAK while the client is perceptively in RENEWING
>        state is illegal (despite its presence on the state
>        engine in 4.4, this process is never codified in text).

        Stig says: under what circumstances would you *want* to
        NAK a renewal that you received through the relay anyway?

Kim responds:

Ignoring for the moment Stig's point, there are many times that
renewals are NAK'ed in practice, and all clients known to us will
honor that per the state transition diagram and move back to INIT
state on a NAK.  The common case is that the IP address the
client has is deemed to be "uncorrect" for some reason other than
network connectivity, and the client is given a NAK to cause them
to DISCOVER for a different IP address.

This comes up in several different situations in our support for
client-class or in cases of client registration.  Sometimes a
client is given an IP address which is "restricted" in some way,
and then after registration, is given a "better" IP address.  In
most implementations of which I am aware (including ours), when
it is time to switch from a "restricted" to "better" IP address,
a NAK is returned to the renew for the "restricted" IP address.
We've been doing this with countless installations for at least 7
years, and have heard of no problems.

Probably this is in part because of the state transition diagram
and probably this is in part because the code in most clients
that processes renewal responses is closely related to the code
that processes rebind responses, which the text in RFC2131 makes
more clear can be NAKed.

We certainly don't have the only server which NAK's renewals, and
I thought that this was old news indeed -- about the state
transition diagram allowing NAK's on renews.

Now, I've never discussed NAKing renews with anyone based on
network attachment, and indeed, our server has code that is
functionally similar that described by David -- we don't NAK a
renew based on network connnectivity, only a rebind.  But that
doesn't mean that in general we can't NAK a renew -- far from it.

So I think the issue at bottom is: what kind of network design
could you have that would allow renews (because you can't NAK
them for network connectivity) and yet would cause NAK's on
rebinds (due to network connectivity)?  This certainly sounds
like a network on which any kind of failover or load balancing
would not work at all well, since rebinds are an integral part of
the failover process.  I can't believe that this is a robust
network design.

Issue #2: Load balancing generates multiple ACK's.

This certainly is an issue, and does make load balancing largely
uninteresting in a situation where you would use the
server-id-override sub-option.  On the other hand, failover would
still work -- you just don't get any effective load balancing.

We've viewed this as the price you pay to talk to a DHCP client
that you wouldn't otherwise be able to talk to, and given the
circumstances, a small price to pay for that capability.

It would be nice to be able to tell a unicast from a broadcast in
the packet forwarded from the relay agent.  That would make load
balancing work and would also allow a solution to #1 and #3.

Issue #3:  Clients can get multiple ACK's to a renew, not just a
rebind.

At present a client can get multiple ACK's to rebind, but not a
renew.  This would go away if issue #2 was solved somehow, since
that is how this situation occurs.

Given that client's expect multiple responses from a rebind,
we've never seen issues with clients from multiple ack's from
renews, for what that is worth.

----------------------------------------------------------

Solution?

If we have the relay agent tell the DHCP server if a packet it
forwards was broadcast or unicast, then the DHCP server could
handle each issue in a way that was not only correct but also
compatible with its current approach.  I think issue #2 is the
only really substantive one, but if we solve that we can solve
them all, so why argue about which are important and which not?

The question comes to -- how to have the relay agent tell the
server the packet was unicast or broadcast.  The obvious answer
is add information to the server-id-override sub-option, a flags
byte perhaps.

But there is a larger problem related to this one that deserves
some discussion:

One major issue with implementing advanced capabilities in the
DHCP server is the lack of option-82 information in the unicast
renew packets.  One solution to this is to never answer renews,
but just answer rebinds, which works but is less than optimal.

A viable but flawed solution to this lack of option-82
information is to have the DHCP server put the giaddr into the
server-identifier sub-option even if it *didn't* get a
server-id-override sub-option from the relay agent.  This will
cause all packets to be sent to the relay-agent.  All relay
agents known to us will accept packets unicast to them and put
option-82 information in the packets and forward them on to the
DHCP server.

But of course this approach is flawed by the same three issues
above.  

However, if we get the relay agent to tell the server if a packet
was broadcast or unicast, then this could be a viable way to
ensure option-82 information in all renewals.  But we can't
extend the server-id-override sub-option to do it.  We would need
a new sub-option to signal that a packet with option-82
information was unicast to the relay agent.

Perhaps a "unicast-to-relay" option-82 sub-option could be defined
that would be used whenever a relay agent forwarded on a renewal
that was unicast to it.  This would be a zero-length sub-option.
It would solve the general problem of telling a unicast from a
broadcast packet apart that came to the relay.

This would be in addition to the server-id-override sub-option
(if any) that might be in the packet.

Something to think about...

Cheers -- Kim

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Mar 2006 14:24:29 -0700

> transition diagram allowing NAK's on renews.

It is.   The Nominum DHCP server and the ISC DHCP server can both NAK renewals 
as well, if the client is no longer allowed to have a particular IP address 
that it's trying to renew.   This is very old news indeed.

> doesn't mean that in general we can't NAK a renew -- far from it.

Right, and in fact server override makes it more likely that things will 
function correctly: because we are now intercepting the DHCP client message 
at the relay agent and setting giaddr, the server can be *sure* whether the 
client's IP address is valid on the link to which it is connected.   With 
unicast renewals, we have no way of knowing, and indeed we have to guess.   
So server override actually takes us down a cleaner and safer code path - it 
makes things better, not worse.

> balancing work and would also allow a solution to #1 and #3.

Actually, there's another way to look at this: we have an opportunity to solve 
this problem now.   We could define a way to do load balancing at the relay 
agent (in a separate draft), and require that relay agents that implement 
server override also implement load balancing.   This might be a thing worth 
considering, since currently the load generated by forwarding renewals to 
both servers will be substantial.

> renews, for what that is worth.

Furthermore, if the servers are correctly configured, the renews should be 
interchangeable - the only difference will be which server gets picked, and 
this is immaterial because with server override, there will never be a case 
where load is directed to a particular server based on whether or not it was 
the server that renewed a particular lease.

> is add information to the server-id-override sub-option, a flags

I don't think this is necessary or worthwhile.   I don't see any upside in 
sending this flag, because, as you say, existing clients support DHCPNAK at 
DHCPRENEW.

> but just answer rebinds, which works but is less than optimal.

I thought the whole point of server override was to make sure that every 
packet, renewal or not, went through the relay agent, and thus was elegible 
to have option 82 added to it.   Not so?

Anyway, from my perspective, I think that the right thing to do here is:

(1) allocate the suboption code now, so that implementation isn't held back by 
the roadblock I'm about to suggest (I don't *think* we are required not to 
allocate a suboption code prior to RFC).

(2) Write a new draft that describes how relay agents do load balancing.   
[[Short summary - they get the balance mask from the server somehow; they use 
it to decide where to forward _any_ DHCP packet; they check the value of the 
secs field and forward to all servers if secs is over some preconfigured 
limit.]]

(3) Require that conforming implementations of server override also implement 
the relay agent load balancing protocol.

I think that this would do it.   I think the DHCPNAK issue is a red herring.

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 14 Mar 2006 16:40:38 -0500

>to have option 82 added to it.   Not so?

        Well, yes, but the relay agent gets to decide that, for
        the server-id-override suboption to be operative.   It
        isn't so much for option-82 as it is to do the
        forwarding, since the DHCP server may not be able to
        communicate with the client at all due to MPLS/VPN
        configuration.  But the relay agent is in control
        when using the server-id-override suboption.

        The other case is where we don't want to have to tell the
        relay agent to tell the server that it should do the
        giaddr as server-id thing, but rather where we want to
        server to be able to do it on its own.  It *can* just put
        the giaddr into the server-id option.

        But, if it does, then the failover is messed up (along
        with load balancing).

        Thus, I think it might be nice to have the relay agent
        tell us whether it was a broadcast or unicast in a
        separate sub-option from the server-id-override.

        More later on the rest of your email -- I just wanted to
        touch on this one issue now.

        Thanks -- Kim

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 16 Mar 2006 09:29:22 -0800

Sorry I can't respond yet to deeper replies.  It's 'all hands week'
here at ISC, everyone in the company is at 950.  I only have a few
minutes here before the madness begins again today.

I will reply eventually, or at the very least you can track me down at
the hotel starting on the 18th at 4pm or so.

> please bare with me and let me know if my observations are wrong.

I'm probably guilty of flooding the WG with text.  I've already
observed that my message has become distorted under the weight
of its own delivery.

> DHCPNAK should be sent in response to RENEWALs. Also, if DHCPNAKs were 

If a document gives specific guidelines on what to do with a particular
element of operation (such as in this case, I believe), and gives no
MAY behaviour for alternative behaviour, then I have to understand that
to be a MUST NOT.

If we allowed every behaviour that simply was not strictly specified in
the draft to be 'reference behaviour', our implementations would vary
wildly and incompatibly.

At any rate, I have to agree: The document simply does not say you may
produce DHCPNAK in repsonse to a client in RENEWAL state.  It /does/
say in impossible to misinterpret language very specifically when and
how to produce DHCPNAK responses to clients in REBIND state (through
implication).

ISC DHCP today does not do produce DHCPNAKs on the basis of network
attachment when the client is perceivably in RENEW.  It sometimes produces
DHCPNAKs when explicitly configured to do so by an administrator (for lease
ownership permissions reasons for example).  It is this default, out-of-
the-box condition that must remain true to reference (even though, as I've
said, many of ISC DHCP's default behaviours are not, these are bugs).  We
know and expect admins to break with reference regularly, but it must be
their decision to do so.

That is the basis of our company policy as I am presently given to
understand it.

As a consequence, since I understand and believe I have documented
the references to conflict, and it's my belief that my employer will
interpret them the same way, to implement this option in the ISC
DHCP package with the reference as it stands today would be to
willfully endanger my own job.

And I like my job.  Really.

All that said, I'm possibly the only person on this list with this
limitation.  If the WG is saying collectively "we produce conflicting
drafts, deal" then hey, I think the WG can do that, and I guess I'll
have to deal.

It's perfectly reasonable to expect me to produce a clarification
document (that then becomes reference ISC can implement to) to later
allow ISC DHCP to implement this draft.

Or to simply never implement this draft if I can't find the time for
it.

These are all perfectly valid solution sets.

> client uses the relay from which it initially got the address.

Well, at least, we hope it will always succeed.

In my Nov. message, I believe I documented a case where it will not
succeed (where the relay or server is reachable via 802.1q trunking).

Or at least, we hope it won't succeed.  If a client changes networks,
is now on the wrong network, and reaches the relay for its unicast
RENEWAL because of contrived mac addressing, we hope the relay will
still put the right address in the giaddr to indicate that the client
is now on the wrong network.  I've pointed out several contrivances
of implementation that may cause a relay to indicate the wrong network
(meaning, that the client is still attached to the right network).
These contrivances would have worked just fine when the relay only
had to receive and process packets that were destined to broadcast
addresses.

In these contrivances of implementation, such client requests will
actually get ACKed.  Wether or not they are delivered to the right
or wrong subnet again becomes another issue of contrivance of
implementation (the client may in fact BIND and later RENEW yet
again if all the cosmic tumblers are in place, I can describe
that situation again if people would like).

But at this point this field is starting to look like weeds.

So if we just take it as given that this check doesn't succeed when
it isn't supposed to, and we know the client is on the wrong network,
I maintain as I've quoted that RFC2131 demands the server remain
silent.

So, how does a server in an environment implementing this draft detect
that the client is in RENEW or REBIND, since giaddr was heretofore a
part of that detection?

One perfectly acceptable solution set is that we now specify that
it MAY NAK.

> >that losing the server's ability to sense remote broadcast vs unicast

Unfortunately, I intended this as the main theme, the idea I wanted
to convey with a mere example before it, but instead I seem to have
driven people off into the weeds on the above issue, as if addressing
that one issue would absolve my complaints (it wouldn't).

I am not omniscient.  In my first read through the draft, I'd found
one corner case and one flat out protocol incompatibility with earlier
standard that both trouble me.

I have to imagine that's not the end of problems.

Because I know I'm the newbie on this list.  You guys are all smarter
than me (well, most of you) in every dimension regarding the DHCP
protocol.

I know we can never honestly say we know there aren't any other
corner cases, but can everyone honestly say they've spent time
looking for any?

I am not getting any indication here that anyone has.

Without that, we're being sloppy because our attention is focused
on things we're more entertained with.

> directly, and is not able to verify it.

The draft could specify behaviour in this case - that detection of
network attachment is now made possible (and it would be great if the
appropriate MUST behaviour for the relay is reinforced to make
implementors question their contrivances of implementation) while the
client is in RENEW state.

The furthest it goes is to say "this makes every RENEW into a REBIND"
or something to that effect.

[LBA stuff snipped]
> I agree there is a problem when the relay is configured with multiple 

One possible way forward since we know of at least a few ways to solve
this problem (and I see from skimming there's some consensus in the
replies) is to mention this problem in the current draft (reference
the LBA rfc) and choose specifically not to solve it.

Since I'm the one complaining, and probably the only one whose product
is heavily publically invested in failover features (or else why didn't
any of you notice?), I don't mind being the one to draft the solution.

Even though I already have two drafts I've promised, are sitting on
this workstation's very hard disk in various states of disarray, but
haven't seem to have made it onto this list yet.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Mar 2006 11:33:16 -0700

One entirely plausible explanation for why the draft is vague on this point is 
precisely that it's impossible for the server to be certain what state a 
client is in.   Taking that interpretation, which I think is a valid one, the 
ISC server doesn't need to do anything to remain in spec, because it's simply 
doing what the protocol says to do.

Going beyond the spec and trying to talk about some idealized spec that gives 
idealized MUST NOT instructions that don't appear in the written spec is out 
of scope.   Let's leave the idealized spec out of this conversation, and only 
talk about what the real spec says.

I agree that your extrapolation is valid, but it's not the only valid 
extrapolation, nor do I agree that it's correct (as opposed to valid), nor do 
most implementations I've seen agree with it, nor do most of the other DHCP 
geeks here.   So I don't think there's a lot of traction to be had in obeying 
it as if it were what was actually written in the spec.   And, indeed, when I 
coded up that part of the ISC DHCP server, I chose a different 
interpretation, and as far as I can recall, Paul never fired me for it.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Mar 2006 19:08:43 +0000

> talk about what the real spec says.

It's OK.

This only puts holes in my particular boat, and I can do my own bailing.

> extrapolation, nor do I agree that it's correct (as opposed to valid), nor do 

I think we understand one another, and I'd rather not dwell on the
subject.

It makes me more than nauseated.

> interpretation,

There's another explanation:  It's been 5-9 years inbetween then and
now, and you've forgotten.

I believe the comment matches my interpretation, and the code underneath
it matches the comment.

I can believe that I'd misinterpreted your comment, I've done it before.
But you use fairly specific wording here that I've reused.  Let me share
a snippet of cvs annotate of server/dhcp.c;

1.47 (mellon 09-May-97): local router will be wrong.  In any case, the protocol
1.47 (mellon 09-May-97): doesn't really allow us to NAK a DHCPREQUEST from a
1.47 (mellon 09-May-97): RENEWING client, so we can punt on this issue. */

Which was just a conclusion in a multi-page theme of much the same, but
it's really hard for me not to read this part of the comment as being in
agreement with my interpretation.  "the protocol doesn't really allow".
I'm having trouble believing you meant that rfc2131 allows NAKing RENEWs
when the words you used were "doesn't allow".  It's possible, but neither
can I explain how you let that comment remain over 4 years of revisiting
this code, nor can I understand how you can expect me to interpret it any
other way.

The code directly below it is interpreted by the compiler in only one way
and, again, it matches my interpretation.  It evolved from that initial
comment in 1997 into later reimplementation in 2000 and 2001 as evidenced
by the annotation:

1.47  (mellon 09-May-97): if (!packet -> shared_network ||
1.171 (mellon 30-Nov-00):     (packet -> raw -> ciaddr.s_addr &&
1.171 (mellon 30-Nov-00):      packet -> raw -> giaddr.s_addr) ||
1.181 (mellon 12-Feb-01):     (have_requested_addr && !packet -> raw -> ciaddr.s_addr)) {

That conditional has to result in truth for a NAK to be emitted due to
network attachment mismatches (not administrative configuration burden).

The first conditional is a contrivance of implementation, best ignored
for the purposes of this discussion (weeds that aren't even topical).

The middle two tell us the client is rebinding: giaddr (is only set if
the client broadcast), and ciaddr is set...this is what I mean when I
use the shorthand 'REBIND'.  This draft now changes that, and leaves us
with no way to sense broadcast (we will NAK RENEW ('unicast with ciaddr
set') via a relay).

The last line is a different set of weeds, an implementation failure of
our software, but its choice (to not NAK RENEW at the expense of also
not NAKing REBIND) reinforces my position.  Ignoring these clients,
sending clients back to an INIT state is just painful.  But we're
enduring that pain to remain true to reference: NAK RENEW is illegal.

> and as far as I can recall, Paul never fired me for it.

Oddly enough, Paul has fired me.

He hired me back shortly afterwards.  Something about not being able
to find a replacement "crazy enough" to work on the codebase in
question.

But the message was pretty clear.

It's not quite fair of me to impart that anecdote, however, since Paul
was also never my boss at ISC (he said it, but he and I both knew he
had to get someone else to agree to actually do it, or fire both of
us).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Mar 2006 14:37:26 -0700

On Friday 17 March 2006 12:08, David W. Hankins wrote:
> It's possible, but neither

I wrote that comment before we (the then-current members of the working group) 
had ever talked about the problem.   I am fairly sure that if you look in the 
CVS logs you'll find that it goes back to DHCP 1.0 days, or at the very least 
to DHCP 2.0 days.   I never updated the comment because I had other things to 
do, and wasn't treating it as a high priority (which was a mistake).   One of 
the big lessons I take from the experience of writing the ISC DHCP server is 
that it's always good to have more than one set of eyes on any given piece of 
code, because fear of embarrassment keeps you honest.

Of course, this change in attitude is a big part of why the Nominum DHCP 
Client hasn't been released yet--it actually does take work to keep comments 
up to date, and code clean.

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 19 Mar 2006 20:22:51 +0000

> the failover process.  I can't believe that this is a robust

In my first (Nov) message, I pointed out a contrivance of design
that does precisely that.  I can try again to clarify it, but I
just did so again, and produced so much text I think my point(s)
are lost under its weight (people are more likely to skim).  Being
terse does not come easily for me.

But I do think of it as a robust network design.  We can take
that off-list if you like.

Since consensus appears to me to be in the direction of "MAY NAK
RENEW" at present, I suggested those of us with these stern
limitations of reference interpretation (me, myself, and I) produce
a clarification document that makes this behaviour reference.

I rather wonder now if the WG is really aware that by doing so, we are
implicitly demanding that clients MUST NOT unicast their renewals via
any network other than the one the server/relay is physically attached
to (more technically, DHCP clients MUST use connected routes before
any others, or else they run the risk of being NAKed by a server that
is getting these renewals via a relay which is correctly recording
the ingres interface in giaddr or subnet-selection optionry).

Imagine someone wrote their laptop's DHCP client to unicast their
renewals for their wireless interface via the physical wired
interface...say to save battery instead of expensive 802.11 transmits,
or just for the more reliable transport.  Not that I know of any that
do this.

Or any variety of motivations we can't forsee.

But again without knowing if it was unicast or broadcast to the relay,
we have to wonder if we should NAK or send the client to REBIND by
ignoring them.

Huh.

I'm really not sure documenting this behaviour as reference is the
right thing now.

> still work -- you just don't get any effective load balancing.

I agree, it doesn't obviate failover, just LBA.

> circumstances, a small price to pay for that capability.

I had no understanding that was what this draft was for.  I
think as a consequence that I agree with the IESG comments to
the ends that this draft's use scenarios need to be documented
in greater detail.

Perhaps its my background, but the single most common thing people
want to keep the relay in the loop for is things like firewall rules,
so the relay can snoop current active leases and their expiry times
and put in firewall rules for them (so you don't get ip routing unless
you ask nicely).

Whereas if DHCP clients can not route to their DHCP server, I think
of that as a network failure.

> balancing work and would also allow a solution to #1 and #3.

I have not been thinking in that direction.

We are getting substiantial pushback on even suggesting that #1
exists, much less is a problem worth solving.

So I suspect consensus is moving in the direction towards punting
#1, and producing options to push LBA into the relay agents for
#2.

But honestly, I do prefer this method of solving both problems.  I'll
even tell you why.

If we push LBA into the relays, it is possible certainly, but we ask
the relays to start carrying state they have not had to up until this
point, and it's going to make deployment hard.

Really, which is the harder operation to ask a relay to take on:  "Was
this packet unicast to you (or not)", or, "LBA."

We also open ourselves up to decide upon and solve all manner of
corner cases that are going to arise when you also have a pair of
failover servers behind it.  I'm having some difficulty getting my
head wrapped around how LBA on the relays and LBA on, let us imagine,
failover servers, will work.  Perhaps it's only a fear.

So I don't like the idea of making relays do LBA.  I like that servers
are the only place currently where these hard questions are answered.

> renews, for what that is worth.

Neither have I, but I am measurably young and naive, so I like to
ask questions.

I mostly just don't like not getting answers.

I suspect there is no reason to evaluate #3 further.

> but just answer rebinds, which works but is less than optimal.

Well, up-to-date option-82 information.

> option-82 information in the packets and forward them on to the

Hm.  I suspect most servers already would effectively do this.

One way you solve how to categorize a client by relay agent options
when they send you unicast renewals is to cache the relay agent
option contents on the lease when you give it to the client.

So my initial worry upon always sending a client to the same relay
agent once they've bound (every renewal after that), is that this
might produce a service failure...if the relay fails.  But the worst
case here is that the client goes back to REBIND and we hear from
them via other relays (if available).  At which point we should have
fresh relay agent options.

So, nothing to worry about after all.

> information was unicast to the relay agent.

That would be an interesting way to solve all the problems we've
mentioned so far...in addition to when server-select was in use, also
to work when the server was explicitly configured to force clients to
renew off their relays (differentiating between server and relay
selection of this behaviour).

> broadcast packet apart that came to the relay.

Hm.  I'm queasy about zero length, but I honestly can't argue with
that.  It really is just 'was unicast' we care about.

Thank you, Kim.  I'll continue to think about this.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Mar 2006 13:48:58 -0700

It seems like what you're really saying is that the client MUST send its 
renewal out the same interface that is being configured.   This requirement 
is expressed in RFC3315, for precisely the reason you state, but, as you say, 
it's never expressed in RFC2131.

You're right that this creates a problem - we can't assume that clients do 
this, and indeed there's good reason to imagine they might not, not because 
of the contrived example you mention, but simply because in all likelihood a 
client with two interfaces will use one of them as its default route.   So if 
the DHCP server is not on-link, renewals will always go out one of the two 
interfaces, even when the interface whose IP address is being renewed is the 
other interface.

Hm, but wait, this really isn't a problem, is it?   Because in fact the whole 
point of the server override is to have the client send the renewal to the 
same relay agent that initially relayed the message.   So the only case where 
this becomes a problem is the one in which the relay agent has used server 
override, and in that specific case the renewal should go out the right 
interface because the relay agent will be on-link.

I confess I'm a little confused here.   Does anyone else want to take a stab 
at this mess?

BTW, it would be inappropriate to take this off-list, but it's probably a good 
idea to stop letting the Cc: list grow, since everyone on it (including me) 
is getting two copies of each of your replies.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 20 Mar 2006 02:25:45 +0000

> Hm, but wait, this really isn't a problem, is it?   Because in fact the whole 

That's precisely what I'm wrestling with.

The rub is wether or not there's any advantage to allowing them
this behaviour.

It's possibly just a good idea to keep your renewal with your dhcp
provider on the same network...you can't guarantee two interfaces are
in the same administrative domain (you might get filtered between
the two, and this sends you back to REBIND).  But if you believe that
line then you have to go further than this, in environments where
server-select is not being used you have to use each interface's
default route for each client state engine!

So we're left lamenting that no one ever said a DHCPv4 client can't
send its renew out a different interface, and there are at least a
few reasons I can imagine you might think you want to (which means
there are possibly more) even if you have a "connected" route.  I
also now recall considering, when I was reading Mr. Aboba's DNAv4
draft (excuse me, RFC), making the client keep a configuration active
for a wireless interface (for example) while a wired configuration
was still showing link state.  Keeping it up, renewing it, but not
actually binding to it.  Wasteful, but there's no wait time inbetween
losing link and having net on the wireless (I was thinking of this as
a later extension to being able to switch a single address between two
interfaces by detecting they were in the same broadcast domain).

So, I /might/ want to.

This whole question also evaporates if we just use the indicator Kim
suggests (or any similar tweak), and let vendors choose their own
poison (NAKing RENEW or not).

So I'm thinking now that this is the better part of valour.  It keeps
the LBA calculation off the relays, "keeping them dumb", and the
kinds of things above can at least stay possible, if of questionable
utility.  Maintaining the status quo.

I don't know.  Maybe I need to spend some time to think about how we
can do LBA on the relay and what the positives/negatives are.  Right
now as I think about it, it sounds like a huge mess.  An attractive
mess, but tricky.  Needfully?

> is getting two copies of each of your replies.

Sorry.  The cc: list Ralph kicked off looked like it had been
constructed specifically.