Subject: [dhcwg] "the relay agent reliability problem"

From: "David W. Hankins" <[email-masked]>
Date: Thu, 15 Jan 2009 16:59:22 -0800

In several different places, the most important of which was Bernie's
trials at exploring the Prefix Delegation space, we've found that we
can't quite do what we need to because DHCPv4 and DHCPv6 relay agents
do not receive DHCP configuration reliably in a server/client
exchange.  Additionally, external 'routing protocols' are also
deselected for (network-local) political, religious, or administrative
reasons.

With the new year, I realized we stopped talking about this at some
point.

I think I found a way to very simply sum up my position on how I would
like this area of work to proceed.

I would like for the DHCP client state engine to remain the only
state engine within the DHCP message exchange framework.

So, in the frame of picture that ignores the server lease states.

This implies to me going about solving the relay agent consistency
problem in one of two ways, but I hope there are more, and I'm not
crazy about either of them (they both have difficult challenges, so
I don't think they're good ideas as I describe them, but I think it
has potential to develop);

1) Cause the relay agent to also be a client (on its 'upstream'
   interface, for example).

   This supposes the relay agent will have an IA, so that renew and
   rebind timers can be tuned and used to ensure the relay gets 'up to
   date enough' information, according to local policy.  The server
   would select renew and rebind timers so that the relay would
   receive updated configuration tearing down expired prefix
   delegations' routes on schedule with those prefix's lifetimes.

   As part of the configuration following the IA, the server would
   deliver a set of static route options, directing prefixes to
   delegated clients.  The client would redistribute these routes
   as locally configured.

   There are two more different ways to interpret this class of
   design;

	a) The admin preallocates and pre-statically-routes prefixes
	   to pre-designated global IPv6 addresses behind the relay.

	   The relay may receive these routes via DHCPv6 options as a
	   client, and may also be informed what prefixes to configure
	   on downstream interfaces.

	   The server allocates IA_NA/IA_PD's in matching pairs.  Note
	   this requires PD clients to receive NA addresses, whether
	   they also participate in RTsol stateless global addresses
	   or not.

	b) A different method would be for the server to initiate and
	   potentially complete a "reconfigure" operation with the
	   Relay Agent before each new prefix delegation.  The new
	   configuration map for the relay agent would be updated.

	   This presumes a rather quiet and unassuming client base;
	   that prefixes will be announced and withdrawn rarely,
	   and that renews are far more common.

   In a way "something like this", the device overcomes the problem
   of reliability by engaging in a state engine that guarantees
   convergence of what is essentially configuration state.

   One downside is that the relay's client may have to engage in
   multiple client state engines in order to provide subdivision.
   A single static route map may exceed the 64KB UDP payload limit.

2) Make what is today a relay agent to instead be a 'delegated
   server,' becoming a DHCPv6 client 'upstream' which configures its
   own internal DHCPv6 server 'downstream'.

   In a design of this sort, we would suppose a superset of Ralph
   Drom's container option; "basic DHCPv6 server configuration,"
   obtained from its DHCPv6 client scope.

   The agent would also receive delegated prefixes, which it
   would subdivide and use to address its downstream interfaces,
   and allocate to its own clients.

   In this way, the device overcomes the problem of reliable
   communications with the server by becoming the server in
   the equation.  It can emit or revoke routes according to the
   policies it sets itself.

   One downside is the reliance upon local non-volatile storage.
   It may be that a solution in this area would need to be hybrid
   with some means for the agent to access an external database
   to request storage of new bindings as well as checking for
   existing bindings.  It may be easier simply to let clients with
   such limits solve this problem separately (e.g., with SQL or
   LDAP or what have you).

   Some mechanism for automated reporting of usage upstream might also
   be required.

-- 
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://www.ietf.org/mailman/listinfo/dhcwg