[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Architectural argument for RAs [Re: [69ATTENDEES] DHCP]



On Fri, Sep 21, 2007 at 11:26:11AM +1200, Brian E Carpenter wrote:
> I was interested to notice this in draft-aboba-ip-config-02.txt:
> 
> >3.3.  Fate Sharing
> >
> >   If a server (or set of servers) is needed to get a set of
> >   configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is
> >   preserved if the servers are ones without which the parameters could
> >   not be used, even if they were obtained via other means.  The
> >   possibility of incorrect information being configured is minimized if
> >   there is only one machine which is authoritative for the information
> >   (i.e., there is no need to keep multiple authoritative servers in
> >   sync).  For example, learning default gateways via Router
> >   Advertisements provides perfect fate sharing.  That is, gateway
> >   addresses can be obtained if and only if they can actually be used.
> 
>  ...
> >   ...Typically DHCP servers do not check for the
> >   liveness of the configuration information they provide, or do not
> >   discover new configuration information automatically.  As a result,
> >   there is no guarantee that configuration information will be current.

So should we be advocating "perfect fate sharing" for all protocols?
It makes a certain amount of sense.

To do this, RA-style messages make a certain amount of sense. Of
course, you probably want to send these using UDP multicast in the
general case since most services are not really tied closely to the
network architecture. There may also be a need to provide different
information to the client, if the device implementing the protocol
acts differently depending on client information, so some sort of
client/server protocol might be helpful. Pretty soon you have have
DHCPv6... :)

As far as DHCP servers not discovering configuration information,
there is nothing preventing devices providing service from updating a
DHCP server with state information or a DHCP server checking it, if
this sort of "guarantee" is desirable. Or these devices can implement
tiny stateless-only DHCP servers on their own. I do not know if either
of these models has been pursed before in the IETF (I would not be
surprised, since it seems there are no new ideas in networking), but
maybe someone on this list knows?

--
Shane