DHCPv6 failover protocol?

[John Jason Brzozowski]

See below.

John
===============================================
John Jason Brzozowski
jjmb at jjmb.com
(p) 484-994-6787
(f) 610-616-4535
===============================================

On Mar 8, 2009, at 12:27 PM, David W. Hankins wrote:

> On Sat, Mar 07, 2009 at 12:10:04PM -0500, John Jason Brzozowski wrote:
>> deployment leveraging DHCPv6.  If some form of load balancing is  
>> not in
>> place then one server carries more of the burden that others in a  
>> cluster
>> of DHCPv6 servers.
>
> I didn't mean "no load balancing," I mean "no explicit new algorithm
> or load balancing feature is required."
>
> Meaning, we can do it already.
[jjmb] I see where you were coming from and agree.
>
>
> I think you can write a small 1-5 line function that delivers a
> different preference option to the client depending on which server
> is emitting the option.  Each server would emit a different preference
> for different clients, and you'd rig the algorithm so that there was
> population balance.  (Writing this in dhcpd.conf language may be a bit
> hard right now, but possible I think, and if we knew more about how
> this works we could provide some assist functions.)
[jjmb] I would willing to collaborate here.
>
>
> The client selects the highest preference, and so you load balance on
> a per-client basis by having per-client preferences.
[jjmb] Assuming the clients are compliant.  ;)
>
>
> Of course clients that are Renewing won't pay attention to
> preferences, so if you needed to be able to rebalance after a series
> of outages, you would have to get the client to rebind.  So you might
> just ignore Renews from clients for whom the server isn't the highest
> preference, catching them on the Rebind.  Can't do this right now, but
> it is also trivial (a 'deny booting;' alike in a dhcpd.conf executable
> statement, probably combined with the Preference value selector but
> depending upon the client packet being a Renew).
[jjmb] If the original server is down the client will continue to  
renew until rebind.  If the original server has yet to return the  
client will interact with other available servers.  I think this is  
what you are saying, if so we agree.
>
>
> But RFC 3315 is very mealy-mouthed on the subject of how a client
> selects an Advertise to Request.  It permits a client to ignore the
> preference if there is an Advertise "it likes better," but doesn't
> go into details.  So this is why I am not "sure" we need an explicit
> load balancing algorithm for DHCPv6 - it depends upon client
> implementors to see wisdom RFC 3315 doesn't currently encode (they
> might just give up at the current language and ignore the preference
> option).
[jjmb] My experience to date suggests that preference rather high in  
the criteria list when select which ADVERTISE to select.
>
>
> So it "waits to be seen" in my mind.
>
>> This creates some notion of hierarchy amongst servers and this also  
>> does
>> not address the issue of what happens when one or more servers go  
>> down.
>
> One other note is that I still have a very specific inclination to
> what the word 'failover' means, since the current DHCPv4 software has
> something we call 'failover.'
>
> 'Clustering', on the other hand, is a different thing in my mind, with
> slightly different design constraints and requirements (which vastly
> change the implementation), and I think we have always needed a
> clustering solution independent of DHCPv4's failover...we still will
> with DHCPv6.
[jjmb] I believe DHCP servers will be clustered together to provide  
DHCPv6 services.  There are some areas of flexibility that we get when  
moving to IPv6 compared to IPv4.  There is a limit to how far this  
will go practically speaking.
>
>
> Clustering, actually, is how I would like to bring multi-core support
> to ISC DHCP.
>
> -- 
> 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
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users