Re: Questions about server's use of giaddr

[Jim Fletcher <[e-mail]>]

> From [e-mail]  Wed Jan 31 05:55:54 1996
> Date: Wed, 31 Jan 1996 05:55:51 -0500
> To: [e-mail]
> From: [e-mail] (Ralph Droms)
> Subject: Re: Questions about server's use of giaddr
> Cc: [e-mail], [e-mail]


Ralph Droms wrote in response to my questions...

> I think the prevailing opinion is that this function will need to be
> provided by DHCP servers.  The relay agents could also make a choice of
> which address to insert into 'giaddr'; to date, we've tried to make the
> requirements on relay agents as simple as possible and so relay agents
> don't look like good candidates.

> The idea, then, would be to include with DHCP servers some knowledge of how
> to select a client address based on 'giaddr'.  I.e., given a specific
> 'giaddr', the server has a pool of available subnets to choose from (all of
> the logical subnets that share the wire with the address in 'giaddr') and a
> policy for how to choose from that pool.

> - Ralph

Thanks for your reply Ralph.

Having a server which could make these choices would make
my problems go away.  For now however, I'll have to set giaddr
"intelligently" to try to distribute address assignments
throughout the address space defined by my logical subnets.

I think I have a way to do this giaddr assignment which will
work.  I would appreciate it if people could look this over
and let me know what they think.  Please respond to my email,
as I am still not on your lists, however I will be requesting
to get added.

First a little product background.  I am implementing the
relay agent in a Hybrid Fiber/Coax, or HFC router.
On the HFC side of the router, there are numerous pairs of
RF receivers/transmitters.  A set of IP Subnets are configured
for this HFC side of the router, however they can't be assigned
to particular RF pairs.  Hence the need for me to find a way
to set giaddr.  Note that the convention exists that the router
owns host address .1 for each subnet defined.

I think the following scheme can be used to set giaddr for
any client DHCP request I need to relay to a server.


 (1) If the packet contains the requested_ip_addr option, the router
     has a subnet defined which is valid for the address requested,
     and the address is not .1, then set giaddr to the router's
     address on the subnet.

                               ELSE

 (2) If the packet contains a non-zero ciaddr, the router has a subnet
     defined which is valid for the ciaddr present, and the ciaddr is
     not .1, then set giaddr to the router's address on the subnet.

                               ELSE

 (3) Choose giaddr from the group of subnet (.1) addresses configured
     on the router.  I will choose so that client assignments will be
     distributed across the address range defined by the set of configured
     subnets.  I think this case will only be hit for DISCOVER packets.
     If I choose giaddr from a subnet which has no more free addresses
     in it, I am assuming the client will receive no OFFERS, timeout,
     then send another DISCOVER which will get a different giaddr assignment.
     This may mean it could take a long time for a client assignment once
     my subnets start getting used up.  I'm hoping client timeouts are 
     configurable.


Thinking about how the different client packets would have giaddr set...

NOTE: Assumptions on the setting of ciaddr and requested_ip_addr option are
      based on the draft rewrite of RFC1541 (Nov 1995).  I know this is a
      no-no, but the current offical RFC isn't specific in some cases.  This
      could mean that there will be implementations where things are set 
      differently, but I think checking the option first, then ciaddr is
      the right thing to do.  I will be checking out how some current 
      implementations work, to be sure...

DISCOVER - giaddr will be set via (1) if the requested_ip_addr option is present,
           else giaddr will be selected via (3), since ciaddr is not set
           in DISCOVER packets.

REQUEST(SELECTING) - giaddr will be set via (1), as requested_ip_addr option
                     is present, and ciaddr is 0.0.0.0.  If I find this not
                     to be the case in current implementations, I'll have to
                     remember what the DISCOVER giaddr went out as, unless
                     ciaddr is set correctly, thus (2) will handle it.

REQUEST(INIT-REBOOT) - Same as REQUEST(SELECTING)

REQUEST(RENEWING) - giaddr will be set via (2), as ciaddr will be set.

REQUEST(REBINDING) - Same as REQUEST(RENEWING)

Again my big concern is that current client implementations don't
make appropriate use of ciaddr and requested_ip_addr option.  I still
think this will work, but the surest way is to analyze implementations
in the lab.

Thanks for you help,

Jim Fletcher

[e-mail]