server-to-server protocols

"Hibbs, R Barr (rbhibbs)" <> Fri, 11 April 1997 22:53 UTC

Received: from cnri by id aa22404; 11 Apr 97 18:53 EDT
Received: from by CNRI.Reston.VA.US id aa21794; 11 Apr 97 18:53 EDT
Received: from by; (5.65v3.2/ id AA02439; Fri, 11 Apr 1997 17:09:27 -0400
Date: Fri, 11 Apr 1997 17:09:27 -0400
Message-Id: <9704111959.AA23864@ns.PacBell.COM>
Precedence: bulk
From: "Hibbs, R Barr (rbhibbs)" <>
To: Multiple recipients of list <>
Subject: server-to-server protocols
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: Worldtalk (NetConnex V4.00a)/MIME

First, thanks to Bob Cole and Kim Kinnear for the great work they've done in 
expanding Ralph's outline into a couple of different, viable proposals.

Now I'm going to muck up the works by introducing to the discussion a very 
tricky problem.

The fundamental question that I am asking is 'Just what is the nature of 
what the server-to-server protocol is trying to accomplish?'  In particular, 
are we attempting to synchronize binding information (alone) among servers, 
or are we attempting to enable one server to take-over from another by 
synchronizing configuration information?

A small example will help clarify what I mean:

Assume two servers, one on each of two subnetworks (for example, and, that are connected to each other by a 
bridge, creating a shared network.  As occasionally happens, the network 
administrator determines that an additional router is needed for the 198 
subnet.  By whatever means is available to the administrator, the IP address 
of the new router is added to the configuration information used by the 
servers to construct an OFFER.  Thereafter, an OFFER constructed by either 
server would include the new router in its vendor options list.

Now, let's introduce a few failures to the mix. . . .  Just after adding the 
new router to the server physically attached to the 198 subnet, and before 
the 209 server can be updated, let the bridge between the segments fail. 
 Let the failure be long enough that one or more leases need to be re-bound. 
 Because we were operating a shared network, let's identify the expiring 
leases as subnet 198, but on the 209 segment.  Let's say our 
server-to-server protocol has informed the 209 server about all previous 129 
leases, so presumably the 209 server can step in and satisfy the rebinding 
request(s).  But what routers is the client told about?  Clearly only the 
router(s) that the 209 server knows about at the time it satisfies the 
request, so when the bridge is repaired or replaced, clients with leases 
re-bound during the outage will know only of a subset of routers available 
to them.  Probably no big deal, right?  Even if network congestion or 
failure of the "known" router(s) occurs there isn't much we can do about it.

But what if our two servers have subtle differences in their client 
configuration process, either because they come from two different vendors 
or are provided (either intentionally or accidentally) with different 
configuration information and the vendor option in question is not so 
obvious as a router?  Is it our intent with the server-to-server protocol to 
permit each server in the group to OFFER to a client a lease that is 
essentially identical to that of its "home" server, or when a different 
server re-binds a client, will the client receive a lease that reflects the 
environment of the new server?  Is the choice of approach a big deal or not?

I suggest that a client "belongs" to many different classes, simultaneously, 
depending on server implementation as well as the DHC protocol specs.  I 
think these include default host requirements values, enterprise defaults, 
intranetwork defaults (assuming an enterprise operates multiple, potentially 
disjoint intranets), server-class defaults, server-specific defaults, shared 
network defaults, subnet-specific defaults, user-class defaults, 
vendor-class defaults, implied hardware-class defaults (based on MAC 
address, for example), domain defaults, host defaults, and client-suggested 
values for options.  How all of these classes overlay and interact with each 
other may very well be an impossible problem to solve, but I believe that 
for the server-to-server protocol the question comes down to 'When we inform 
another server of a lease binding, do we tell it the results of the 
configuration process that created our OFFER, or do we supply it sufficient 
information so that it can duplicate our process in the future?'

Our selection of an approach probably will greatly affect the 
interoperability of the server-to-server protocol, and may also have the 
effect of pre-supposing administrative methods to be used by network 
managers to configure DHC servers which operate in a group.  While I 
currently lean towards sharing results rather than sharing process, I 
haven't thought through all the implications of each approach, so, I invite 
comments and criticism. . . .

 --Barr Hibbs
  370 Third Street, Room 207
  San Francisco, CA  94107-1279