[dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-protocol-04

kkinnear <kkinnear@cisco.com> Thu, 02 February 2017 18:58 UTC

Return-Path: <kkinnear@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 80FDD1294F2; Thu, 2 Feb 2017 10:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oFoHfUFHpkG1; Thu, 2 Feb 2017 10:58:27 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A2A129511; Thu, 2 Feb 2017 10:58:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2259; q=dns/txt; s=iport; t=1486061907; x=1487271507; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RNDr2/rKbgqFjLpCSp70kJ/aWh9SUt2uiDGtQrVW6sU=; b=MJX9twSBSnuVf1dMaHamBUm1iGxXiJHIGKfm0YRizZM2Fhfxp0W/SDRC LApW/HmKtHsSVyxiGksIW9aF68qB1MFhWV/xypOpeSGJA0bfEMYSRNvaP W47VnpaQ9HX0DN1G4o/k1USH1VQdOgLs11ODn452Vqw83KqAH31tKw8wi o=;
X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="379919429"
Received: from rcdn-core-9.cisco.com ([]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 18:58:26 +0000
Received: from [] ([]) (authenticated bits=0) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v12IwObv013283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 18:58:25 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: kkinnear <kkinnear@cisco.com>
In-Reply-To: <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie>
Date: Thu, 2 Feb 2017 13:58:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <74FB30F1-234A-4D1C-BF3C-ED4DAA4C3F4E@cisco.com>
References: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie>
To: dhc-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: kkinnear@cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/jU4xa-BVxQnXX32wcyT9Q0qrrHU>
Cc: Kim Kinnear <kkinnear@cisco.com>
Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-protocol-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 18:58:28 -0000

I have submitted a new version of the DHCPv6 Failover Protocol:


https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/>

which reflects changes resulting from the IESG and directorate reviews
to date.  All of these changes are to explain things more clearly or
explicitly.  None of them alter the intended operation of the

  * Added a sentence at the end of the Security Considerations
    section saying that if authentication of failover partners is
    desired, that TLS SHOULD be employed. [Kathleen Moriarty]

  * Significantly expanded the Security Considerations section to
    discuss some of the threats and when you might use secure and
    insecure mode.  [Ben Campbell]

  * Added clarification as to the use of the OPTION_F_PROTOCOL_VERSION
    option in the CONNECT and CONNECTREPLY message. [Ben Campbell]

  * Added information at the beginning of the Introduction
    describing the failover protocol and pointing to the DHCPv6
    Failover Requirements, RFC 7031. [Christer Holmberg]

  * Included a reference to RFC 3315 when the DHCPv6 server is first
    mentioned.  [Christer Holmberg]

  * Removed the term "DHCP service" from the Introduction as well
    as one other section of the draft, replacing it with "a service to
    DHCP clients". [Christer Holmberg]

  * Added text to the beginning of Section 4 Failover Concepts and
    Mechanisms, that clarifies that these concept and mechanisms are
    not present in RFC 3315, are required for failover, and are
    supported by the failover protocol. [Christer Holmberg]

  * Changed all instances of "this protocol" to be "the failover
    protocol".  [Christer Holmberg]

  * Added a pointer in the Security Considerations section to Section
    9.1 of RFC7653 which describes how two DHCPv6 servers can decide
    to use or not use TLS when connecting. [Stephen Farrell]

  * Added a paragraph in Section 6, Connection Management giving
    an overview of how connections are created and used by the
    failover protocol.  [Mirja Kuhlewind]

Regards -- Kim