Subject: [dhcwg] State of DHCPv6 Failover Drafts

From: Kim Kinnear <[email-masked]>
Date: Fri, 20 Mar 2015 18:46:03 -0400

As some of you may remember, we have published an RFC containing
DHCPv6 Failover requirements as RFC 7031:

  https://tools.ietf.org/html/rfc7031

Then we produced a DHCPv6 Design draft, which passed WG last call,
and was on its way for IESG (or is it IETF?) review:

  http://www.ietf.org/archive/id/draft-ietf-dhc-dhcpv6-failover-design-04.txt

Ted stopped this process, and said that the design draft couldn't move
forward as-is, but we needed to take a DHCPv6 failover protocol draft
forward together with a DHCPv6 failover design draft.  Which was a bit
of a show-stopper, as the protocol draft is by far the most difficult
(to say nothing of being the longest) of the three drafts necessary
for DHCPv6 failover.  And it wasn't even started at that point.  I did
some early hacking on the two drafts a bit over a year ago, but
haven't had time to focus on moving the protocol draft forward.  Until
recently.

I have what I believe the basic structure of the protocol draft
complete at this point, with most of the details filled in.  I didn't
make the Dallas IETF submission cutoff, but since there wasn't time to
really discuss it in the meeting at Dallas, that isn't a big deal.

Here is the first version of the DHCPv6 Failover Protocol draft:

  https://github.com/tomaszmrugalski/ietf-dhcpv6-fo/blob/master/draft-ietf-dhc-dhcpv6-failover-protocol-00.txt

This still needs some serious work, but the basic organization is
complete enough for you to see what you think about it.

I will be at the DHC WG meeting in Dallas next week, and would be more
than happy to discuss the protocol draft with anyone interested after
the meeting.

--------------------

There are several things left to do:

  1. The state descriptions need to get a solid edit pass.  They are
  pretty good, but still a bit generic as they came from the design
  draft.  There are a number of places where the "it could be this way
  or it could be that way" need to become "it is this way", as befits
  a protocol draft.

  2. The proportional allocation mechanism will be used for delegated
  prefixes, and not for IPv6 addresses, and that has to be clarified
  in a number of places.

  3. DDNS has been sketched in, but still needs to be clarified and
  tightened up.

  4. The whole draft needs several good reads to:

    o look at accuracy of BNDUPD/BNDACK processing in particular

    o clean up language

    o work on accuracy in general

That said, it at least *exists* at this point.

I have done only a little work on the design draft at this point.  My
theory is that we should get the protocol draft correct and complete
(since it has to stand on its own regarding the "how to" do the
protocol), and then move back to the design draft and tidy it up to
talk about the things that need additional explanation.

----------------------

Regards -- Kim