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

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 21 November 2017 06:26 UTC

Return-Path: <swmike@swm.pp.se>
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 509D012EB2B; Mon, 20 Nov 2017 22:26:02 -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=swm.pp.se
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 jW5QS-H9p4C8; Mon, 20 Nov 2017 22:26:01 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 D12AD12EB3B; Mon, 20 Nov 2017 22:25:35 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id D811CB1; Tue, 21 Nov 2017 07:25:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511245533; bh=fkBGjQ941tGk3kC34q5Zsia2PYuYDqFxiJTlwq7su5w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p5qDXCLmRyApjqZ4ZVGIkH9hPdYT18EtlLgZbJ44XhOFmjuN0Grqd9K1TCvRkZpOJ x3CNtrpB4hBuKM17wdlbdwAgMgaPrGGpxnaE2jpnu/g5G3SWJcEZHpMOhgU/GXt7lC 2PYyyQF4dTanTK9bLekpwMuhXcWnTxPQZzDVJD7U=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D4261B0; Tue, 21 Nov 2017 07:25:33 +0100 (CET)
Date: Tue, 21 Nov 2017 07:25:33 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Mark Smith <markzzzsmith@gmail.com>
cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6MAN <6man@ietf.org>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
In-Reply-To: <CAO42Z2x8h7RVXP5Hy4vaDXc8kpZBSxJAq=Z7xXTsNN4R8E-Qgw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1711210720520.32099@uplift.swm.pp.se>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2x8h7RVXP5Hy4vaDXc8kpZBSxJAq=Z7xXTsNN4R8E-Qgw@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0TddzWyIZytB8WEi1I3chBh0qgU>
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: Tue, 21 Nov 2017 06:26:02 -0000

On Tue, 21 Nov 2017, Mark Smith wrote:

> Hi Fred,
>
> I think this fundamentally violates the principle that the network is
> application agnostic or transparent, allowing it to support any new host
> residing application without any upgrades to the network. I think the
> principle of network application transparency should apply to application
> configuration.
>
> We don't have to upgrade routers to carry new application protocols, we
> shouldn't have to upgrade routers to support configuring new applications.
>
> "Internet Transparency and Application Configuration"
>
> https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

DHCP is a pain for rapidly changing (perhaps mobile) environments. It's 
fundamentally a polling protocol where the network hands out resources for 
a certain amount of time, and there is little chance to invalidate them. 
It's stateful.

Devices need addresses to communicate. So if environments that are dynamic 
and require fast/short setup times to gain addresses, then we need the 
network to support that.

This is not an "application" as in a program running somewhere. This is a 
deployment scenario where devices need addresses quickly with short 
turnaround times and in a bandwidth constrained environment. Saying we 
can't change the network to support this is just silly.

So you think 6lo was a bad idea and violated the network agonostic 
principle?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se