Subject: [dhcwg] Summary of the 3315bis discussions in Dallas

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 07 Apr 2015 21:45:45 +0200

These are the notes from the DHC WG meeting in Dallas that are related
to 3315bis work. They reflect what was the general consensus in the
room. If you didn't participate and have a different opinion, please
speak up. If we don't hear any objections, we'll assume that the
consensus on those topics was reached and the changes will be applied in
the 3315bis draft.

During the DHC WG session at the Dallas IETF-92 meeting, several
DHCPv6bis issues were discussed. We are posting this summary to the list
to confirm that (a) our summary of each issue is correct, and (b) that
no one has any objections to the intended actions. The issue ticket
numbers referenced can be viewed at
http://trac.tools.ietf.org/group/dhcpv6bis/report. The slides used are
at http://www.ietf.org/proceedings/92/slides/slides-92-dhc-9.pdf. This
is to continue work on http://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis.

#142 - Reorganize server/client behavior? (Slide 5)
– No objections

#144 – Clarify unknown options handling (Slide 6)
 – No objections

#81 – Should protocol options be included in ORO? (Slide 7)
– Ted suggested we might want to request IANA to add a new column to the
options table as to whether it MUST be in ORO for the client to receive.
This seemed like a good way to solve this problem. The default needs to
be “YES” unless the option definition document says otherwise. Perhaps
this should be done as a separate draft (Bernie’s suggestion while
working on this summary).

#18 – Is ORO mandatory? (Slide 8)
– Servers MUST accept messages without an ORO. SOL_MAX_RT MUST be in
ORO, if ORO is included, for Solicit/Request/Renew/Rebind (INF_MAX_RT
MAY be). INF_MAX_RT MUST be in ORO, if ORO is included, for
Information-Request (SOL_MAX_RT MAY be).

#68 – Prefix Length of Addresses (Slide 9)
– Yes, this should be documented. See DHC WG discussion thread starting
with http://www.ietf.org/mail-archive/web/dhcwg/current/msg16391.html.

#82 – IA_ADDR with :: Address (Slide 10)
– Discourage use of IA_ADDR and IA_PREFIX with all 0s (no hints or
requested address/prefix).

Ted suggested we document how clients get new addresses – by using a new
IA_ID with an IA_NA or IA_TA.

#114 – Clarify “hints” (Slide 11)
– This has to do with clients requesting a prefix delegation prefix
length. Bernie to send an email to WG to clarify issues and suggest text
changes.

#70 – Validate addresses in IA (Slide 12)
– The participants felt that there was no need to add anything more or
otherwise make changes in this area.

#86 – Information-request in Delayed Authentication Protocol (DAP)
(Slide 13)
– Ted suggested we remove DAP from DHCPv6bis as it is not
known to have been deployed by anyone. As far as we can tell, there's
only one implementation. (Tomek comment added during writing those
minutes: I did implement it in Dibbler. The mechanism, including option
formats, was underspecified and I had to make judgement decisions that
would likely prevent interop. I'm not aware of any other implementations
or deployments that use DAP in Dibbler).

Reconfiguration Key Auth. Protocol will be retained. This seemed like a
good way to solve this issue and reduce the size / complexity of the
document.

Tomek's comment while editing those notes. I strongly support this
proposal. That is especially important if our original plan to promote
DHCPv6 to Internet Standard still applies. In particular, RFC6410,
section 2.2 defines the maturity requirements for a standard. Note item 3:

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

Delayed Authentication Protocol matches this description. It is unused
(has anyone heard about anyone deploying this feature beyond lab tests?
I haven't.) and it has significant implementation complexity. Since
nobody deployed it in 11 years, then it's not usable. Let's get rid of it.

Tomek & Bernie

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Apr 2015 09:59:15 -0700

At Tue, 07 Apr 2015 21:45:45 +0200,

> or deployments that use DAP in Dibbler).

WIDE DHCPv6 supports DAP (even before the birth of Dibbler, I
suspect:-):
http://sourceforge.net/projects/wide-dhcpv6/

If my memory is correct, there was even interoperability testing (for
DHCPv6 in general, but also covering DAP) many years ago, so there
should have been at least one other implementation of DAP than the
WIDE implementation.

I'm noting this just to make the implementation status more accurate.
I have no objection to the proposal of removing DAP from 3315bis (in
fact, I guess I once even suggested that myself before).

--
JINMEI, Tatuya