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 --------------------------------------------------------------------
- RE: Combining IPv6 ND and DHCPv6 into a single, u… Bernie Volz (volz)
- Combining IPv6 ND and DHCPv6 into a single, unifi… Templin, Fred L
- RE: Combining IPv6 ND and DHCPv6 into a single, u… Templin, Fred L
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Sander Steffann
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Mark Smith
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Mikael Abrahamsson
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Lorenzo Colitti
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Mark Smith
- Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 … Lorenzo Colitti
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Michael Richardson
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Fred Baker
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Michael Richardson
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… STARK, BARBARA H
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Brian E Carpenter
- Re: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Brian E Carpenter
- Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 … Lorenzo Colitti
- RE: [v6ops] Combining IPv6 ND and DHCPv6 into a s… Templin, Fred L
- RE: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 … Templin, Fred L
- Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 … Brian E Carpenter