Subject: Re: [dhcwg] DHCP hackathon in Berlin?

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 1 Jun 2016 12:41:36 +0200

Just a small update regarding hackathon.

Bernie and I received a couple of responses so far. One new topic has
been proposed and seems to be getting some traction: RFC7550/RFC3315bis
changes. There will be at least two server implementations to be tested:
Cisco's CNR and ISC's Kea. We're lacking client support, so the plan is
to hack a client during the hackathon. It seems the easiest open source
client to modify is Dibbler, but we're also looking at the ISC DHCP
client modification.

There's a team from Tsinghua university that's interested in developing
YANG module for DHCPv6 server. The code to be extended is Kea.

We also have one newcomer (both to IETF and to hackathon) who is
interested in participating! Welcome!

Please keep in mind that IETF is about rough consensus and running code.
We usually focus on the consensus part, but here's your chance to help
with the running code as well.

Tomek

On 11.05.2016 18:44, Tomek Mrugalski wrote:
> Hey DHCP hackers!
> 
> The IETF meeting in Berlin is not that far off. We'll have an
> opportunity to meet and hack some DHCP code, if we desire so. As usual,
> the question is whether there are enough people interested in hacking
> DHCP? Hackathons traditionally happen during the weekend before IETF, so
> it means July 16-17 this time.
> 
> Please respond if you're interested in participating. Feel free to
> propose the topics.
> 
> Looking at the current topics in DHC, it seems we have 2 areas that
> could definitely benefit from a hackathon. The first one is secure
> DHCPv6. We did some successful experiments in Prague (Kame client was
> interoperating with Kea server), but that was based on an old version of
> draft-ietf-dhc-sedhcpv6-12, which has changed significantly since then.
> 
> Another prospective topic for a hackathon is YANG module. One of the
> concerns raised against draft-ietf-dhc-dhcpv6-yang-01 (or rather general
> comment against any attempts of configuration standardization) was that
> it may be difficult to find a common denominator between existing DHCP
> implementation's configurations. Having a working code
> would definitely be a strong argument in favour of moving this draft
> forward.
> 
> Other topics are certainly welcome as well. Having two or more people
> working in the same feature are better than focusing on independent areas.
> 
> If you're interested in participating, but don't have a code base you'd
> want to work on, feel free to contact me and I'll give you some pointers
> to easily accessible open source implementations that are hackers friendly.
> 
> Tomek
>

---

From: Roy Marples <[email-masked]>
Date: Wed, 01 Jun 2016 12:29:25 +0100

Hi

On 2016-06-01 11:41, Tomek Mrugalski wrote:
> We're lacking client support, so the plan is

No love for dhcpcd for client testing?
http://roy.marples.name/projects/dhcpcd

While I think it should already support the basics of RFC7550 I haven't 
extensively tested it against every bullet point.
It should also support secure DHCPv6 from RFC3315 as well. I'm quite new 
to this list and am unaware if there are any newer RFC documents in the 
works to change secure transactions over RFC3315.

Roy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jun 2016 08:26:25 -0400

https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Are you coming to Berlin?
On Jun 1, 2016 6:29 AM, "Roy Marples" <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Roy Marples <[email-masked]>
Date: Wed, 01 Jun 2016 13:37:38 +0100

On 2016-06-01 13:26, Ted Lemon wrote:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ [3]

Thanks

> Are you coming to Berlin?

Sadly no, I have a prior engagement I cannot miss.

Roy

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 1 Jun 2016 14:37:58 +0200

> http://roy.marples.name/projects/dhcpcd
We'd certainly like to test this implementation, but we need someone
who's familiar with it enough to run it and fix any issues found.

> While I think it should already support the basics of RFC7550 I
> haven't extensively tested it against every bullet point.
That's the idea here. We want to test whether we missed anything, what's
the most reasonable behavior in odd corner cases etc.

> It should also support secure DHCPv6 from RFC3315 as well.
I would be cautious with using "secure" and "3315" in the same sentence. :)

> I'm quite new to this list and am unaware if there are any newer RFC
> documents in the works to change secure transactions over RFC3315.
Yes, there are. First, there's secure DHCPv6 draft that's being
currently actively worked on draft-ietf-dhc-sedhcpv6-12 [1]. It's a
significant step forward as compared to what 3315 offered.

Second, there's RFC3315bis work [2] in progress that hopes to clean up,
clarify and fix lots of issues in DHCPv6. The current draft is
dhc-rfc3315bis-04. There's a whole separate mailing list and issue
tracker [3] dedicated to it. Authors are planning to publish -05 version
in the next couple days. If you're interested in what has changed, we
maintain a changelog (see Appendix A). It may not be exhaustive, though.

One of the changes in 3315bis is the Delayed Authentication mechanism
being deprecated. The mechanism was underspecified, difficult to deploy,
had significant operational burden and its actual deployment in
production networks was extremely limited at best. As there's a new
alternative (sedhcpv6), we decided to get rid of the delayed auth.

Both of those drafts are hoping to go through WGLC (working group last
call) in the next couple months. Feel free to review them and post your
comments here.

1. https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-12

2. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-04

3. https://wiki.tools.ietf.org/group/dhcpv6bis/

Tomek