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

Mark Smith <markzzzsmith@gmail.com> Wed, 22 November 2017 07:19 UTC

Return-Path: <markzzzsmith@gmail.com>
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 BF771128B38; Tue, 21 Nov 2017 23:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.539
X-Spam-Level:
X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4fO-vw4tl3GY; Tue, 21 Nov 2017 23:19:11 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9826126B71; Tue, 21 Nov 2017 23:19:10 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 108so9988677uaf.2; Tue, 21 Nov 2017 23:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjL03jsDFGZA1hGK95LCPER95NpwRhSyHUIX6cVvUIc=; b=WdtzxXEFwLtyR/+lhXTJniW/pwy/GGC6jnmUwCWp8ALIByCWJBGj8b5Zo0V0LOGgIy k4DN5crr6xkIGf/wkmgOipRebt3DIjTkCgeFCqw+AtI3icB25sCOSyXgIXEZTdaiVgul wdLkjNjE+IgjURFGg1XQBbUBQ1Qr4hrcLjReS0Dyk33fHih67a0njg56QKFzYI7KvACi utxnI4CR0F7WIvMJ2k387S065Dg0z3CQ8XohjF6vwVO6gYISf1mr6PkYz2KziMT/VtZe Db/Ydprk23ACgib0EqmOvqfysrO8khLsuRYU3LgXy+Czw5Vg+I/nr624xpx7zq1MeMkh 3FKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jjL03jsDFGZA1hGK95LCPER95NpwRhSyHUIX6cVvUIc=; b=LHScaVlkJn0BICTL4NDVr++zHMYnIt8kdZuwOXPXA4m9MNP+CK1Zo9XbHFFiveW72y Na5R6DgIOr3rHhSATw1kzKimOQrjQoamdXNBZTojcSbRPoM0z07uHghzwmmkMnbID7BZ Wni/Gcn3agjmwWPmEGwRuI9KZEboFvDILq659HNsCZvpA5vuXRdWq0YhKxDy5QYNxYu4 Qn7re2ez1DDF4xpYRurhs9V9b/7uIg2GPg826MfPzb7mzfjENHrJ9cPkS/Tn2iDr/fiV 63gHYOllK7YnhTX5fa4eyd06/8whZc3YNY6AbesaJSdyBjcf3LYinCWlc7n6ykkMHlV8 Rrkw==
X-Gm-Message-State: AJaThX6My8Hnfc9jNSYtlTNet5sFhcAxqrF25tn+oiciCN0VksPBH7NU LpbEehyPfvDgYKPRuwbZuwKswUv8NI6iOeh584o=
X-Google-Smtp-Source: AGs4zMbWAYFLkrmvzs8rT4iWVL7BCYbgHAOJgiD/tEO1YFbqlfnhCv60fSygw90aXlLJHs/yCr5wM1HRyF/wyXSP11M=
X-Received: by 10.176.78.17 with SMTP id g17mr16520680uah.169.1511335149766; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.69.68 with HTTP; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
Received: by 10.176.69.68 with HTTP; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
In-Reply-To: <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 22 Nov 2017 18:19:09 +1100
Message-ID: <CAO42Z2wd0wX3LFhim-ogPkWcLG29iByyGY_eTd3YzPziCoxFzw@mail.gmail.com>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Sander Steffann <sander@steffann.nl>
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>, dhcwg@ietf.org, "v6ops@ietf.org" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="f403043c48acbd0bdd055e8d2213"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/uyYZnVBsXvxyVRxgvmAn2cSAPa8>
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: Wed, 22 Nov 2017 07:19:13 -0000

On 21 Nov. 2017 10:34 am, "Sander Steffann" <sander@steffann.nl> wrote:

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,


So how often do you want to upgrade router firmware? Everytime you want to
deploy an application that uses a new DHCPV6 option?

What do you do when the router vendor says, "we're never going to implement
that new DHCPV6 option in that router model, we don't have enough customers
any more for that model to justify all the development and testing time".
Never deploy the application?

What do you do if the router before says, "that DHCPv6 option is on our
implementation road map, we're expecting to implement it in 6 months
time."? Wait six months before you deploy the application?

Pushing layer 4+ configuration options into ND creates a dependency on
router firmware for application deployment that doesn't exist today in
either ND or DHCPV6.

Another example of this trap. Remember that NTP amplification DoS from 3 or
4 years ago? One place I'm aware of were using their PE routers to also
provide customers with NTP time, and the router implementation was
vulnerable. From memory, the vendor took around a week to release a fix.
Then the next 6 to 8 weeks were spent organising high impact change
controls because router firmware upgrades either required reboots or there
was a hazard of one. The number of PE routers was in the 10s, imagine time
and effort, and vulnerability exposure time if there were 100s or 1000s of
PE routers providing NTP time to customers.

Compare that to if the NTP service/application was not "in" the network,
not "in" the routers' control planes, and as service reachable over the
network. Only patches to the NTP servers would have been necessary, and
there would have been far fewer of those.




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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------