Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

"Templin, Fred L" <> Wed, 19 April 2017 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 097E8127B60; Wed, 19 Apr 2017 06:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2dMLieJJJjmX; Wed, 19 Apr 2017 06:52:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED9AF127868; Wed, 19 Apr 2017 06:51:59 -0700 (PDT)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3JDpwlZ051862; Wed, 19 Apr 2017 06:51:59 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3JDprAH051819 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 19 Apr 2017 06:51:53 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Apr 2017 06:51:52 -0700
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Wed, 19 Apr 2017 06:51:52 -0700
From: "Templin, Fred L" <>
To: Lishan Li <>
CC: Tomek Mrugalski <>, dhcwg <>, draft-ietf-dhc-sedhcpv6 authors <>
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary
Thread-Index: AQHSrj/Om2r5zeyMdU24tzLmWNqPBaHMxxkAgAB4SgD//4s1MA==
Date: Wed, 19 Apr 2017 13:51:52 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913306d77da44ee48136f4e86e26b433XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Apr 2017 13:52:02 -0000

Ø  I have considered this problem. Yes, secure DHCPv6 is incompatible with SAVI.

Ø  If secure DHCPv6 is implemented, SAVI cannot work well and have to be updated.

OK, so you knew this but has it been discussed already on the lists or is
this the first time it has come up for discussion? Because this seems like
a rather significant incompatibility to me. And, when you say SAVI has
to be updated, how do you see that happening? Must the encryption keys
held by the client and/or server be shared with the L2 snooping device?

Thanks - Fred

From: Lishan Li []
Sent: Wednesday, April 19, 2017 6:46 AM
To: Templin, Fred L <>
Cc: Tomek Mrugalski <>om>; dhcwg <>rg>; draft-ietf-dhc-sedhcpv6 authors <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary


I have considered this problem. Yes, secure DHCPv6 is incompatible with SAVI.
If secure DHCPv6 is implemented, SAVI cannot work well and have to be updated.

Best Regards,
在 2017年4月19日,下午9:41,Templin, Fred L <<>> 写道:


RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link from
the DHCP server or relay to the client examines the contents of DHCP messages.
Unfortunately, sedhcpv6 mandates encryption making snooping impossible.

Does it mean that Secure DHCPv6 will be incompatible with SAVI?

Thanks - Fred<>

-----Original Message-----
From: dhcwg [<>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 12:07 PM
To: dhcwg <<>>
Cc: draft-ietf-dhc-sedhcpv6 authors <<>>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

It took a little bit more than planned, but the extra time gave us a
couple more comments.

We did receive a number of in depth reviews with technical comments. In
general, several people praised the significantly improved quality and
clarity of the document. Nobody said that is opposed to this work. So
from that perspective this last call is a success.

However, both chair and at least one co-author feel that an important
concern has not been addressed yet. There currently are no known
implementations or prototypes of this draft. For a typical DHCP draft
that adds an option or two that would probably be fine, but for this
particular draft it is not. For two reasons: First, we feel that this is
an essential piece of the whole DHCPv6 ecosystem and as such require
much more scrutiny then an average draft. Second, security is a complex
matter and any unclear aspects would gravely damage the
interoperability. Jinmei had put it well: "I suspect the current spec
still has some points that are critically unclear, which you would
immediately notice once you tried to implement it."

Given that, we declare that more effort is needed before this work is
deemed ready for IESG. At the same time, chairs would like to strongly
applaud authors' efforts to improve this work. This version is
significantly better than its predecessors. Thank you for your hard
work. You are doing excellent work. Please continue.

Also, to address the concern of missing implementations, chairs would
like to announce a DHCP hackathon in Prague. Details are TBD, but the
primary goal will be to have at least two independent implementations of
that draft. The hackathon will take place the weekend before IETF
meeting (that's July 15-16). A separate announcement will be sent soon.

That is well over 3 months away. Authors and supporters of this work,
please seriously consider dedicating some of your time implementing
prototypes and attending the hackathon, if you can. If you can't we will
organize some means for participating remotely.

Thank you to the authors and to everyone who commented.

Bernie & Tomek

dhcwg mailing list<>