Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Sander Steffann <sander@steffann.nl> Mon, 20 November 2017 23:34 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2BE12E041; Mon, 20 Nov 2017 15:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXNwzk01sj94; Mon, 20 Nov 2017 15:34:42 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8936D120713; Mon, 20 Nov 2017 15:34:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7B8154A; Tue, 21 Nov 2017 00:34:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1511220875; bh=qONPhq/mE69X79DllZWFFCdG/SkTHeT9OQQorW5IbCc=; b=X fF8shk0Q6RimVA7bd7lDHVUGKYa/Y/Om+fhv8SP3kbt+xJM4sBlFL2vMYshbPEMt AeqsFPoDE7hOevG6oZHAJTfAX+l7DI2GKgY7AEYYcvLbEcH+uDTWPk08Udmkq1sc 3Qjx4NXr9zxTByzg34C4Bt46UVkUoEjwjHcr2TZXP4=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DlhoRH3SETBw; Tue, 21 Nov 2017 00:34:35 +0100 (CET)
Received: from [IPv6:2a02:a213:a301:1000:f870:7e30:2e3a:e0db] (unknown [IPv6:2a02:a213:a301:1000:f870:7e30:2e3a:e0db]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5337C49; Tue, 21 Nov 2017 00:34:34 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
Date: Tue, 21 Nov 2017 00:34:32 +0100
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CUw3CpSCflWVCNJ9aof8tT0Uj2E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 23:34:45 -0000

Hi,

> This document therefore proposes a unification of IPv6 ND and DHCPv6 where
> the two functions work together as if they were one. This is accommodated by
> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working
> together as one function, IPv6 ND and DHCPv6 can supply requesting nodes with
> all link-specific autoconfiguration information and any managed address/prefix
> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and DHCPv6 before, but more as a different distribution mechanism: ND for pushing options to all clients on the network, and DHCPv6 for clients requesting specific options for themselves. Just to make it possible to use both mechanisms for all options (MAP/DSLite/etc options in RA would be nice).

What you are doing is another way of looking at it. If I understand correctly you're basically keeping the full functionality of DHCPv6 but using RS/RA as a transport instead of UDP. I wonder what the speed benefit of that would be in practice. Also compared to "impatient" systems that send out DHCPv6 a request before even receiving an RA.

> I would ask these discussion lists to consider what is it that you really don't
> like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way
> the acronym rolls off your tongue when you speak it. Maybe it has an onerous
> stigma of being stateful. But, then I would also ask you to consider what a
> replacement would look like. Because, I think any suitable replacement
> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot* cleaner to implement than DHCPv4. Just plain UDP on link-local and multicast sockets :)  Especially the stateless version is very easy to implement. It's not the ultimate configuration protocol, and for certain things distributing information via RA is a much better fit to the way the network is run. But DHCPv6 has its place and its role, and in certain environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs when the link-layer address in the DUID is based on a different interface than the interface sending the DHCPv6 request. Mostly because the requesting interface's MAC address has always been used with DHCPv4 and is often printed on the outside of the device. But these days LDRA and DHCPv6 relays can tell the DHCPv6 server what the MAC address of the requesting interface was, and we can use that to identify the client (in addition to its DUID). With vendors starting to implement this relay option this is mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure support. That could be used to take away some of the complaints against DHCPv6 (and any client-initiated configuration protocol) that there is no way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need to duplicate its functionality.

Cheers,
Sander