Re: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue
"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 10 November 2020 04:28 UTC
Return-Path: <jmh@joelhalpern.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 E3D1F3A0BE3; Mon, 9 Nov 2020 20:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 nKjgcFSONg7J; Mon, 9 Nov 2020 20:28:02 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B0E1F3A0BE2; Mon, 9 Nov 2020 20:28:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CVZbk3Zvbz1nsT8; Mon, 9 Nov 2020 20:28:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604982482; bh=r5Io9M0Yto15s/JlOE2CubQgzlXl7LhOf/cAa4aIdjM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SavFW5mwCv682++Gxuzzik1aJcwy09GnEQVnsYSnGv0Get5EW1nOKaUAo5OdMC43y cDncfO8lHYlXeMuOiVFQo6AJGUk+g9my+yeqjaSAa/Avk6RAIQm6pVhEOT5MxiMaUM fyxrg+2l4l5fq9GL3389NXwuXCqoXv4QHRIK+cF8=
X-Quarantine-ID: <wSCkwN4U2s6n>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CVZbh0tJ5z1nsSg; Mon, 9 Nov 2020 20:28:00 -0800 (PST)
Subject: Re: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue
To: Ted Lemon <mellon@fugue.com>, Ca By <cb.list6@gmail.com>
Cc: 6man WG <ipv6@ietf.org>, draft-mishra-6man-variable-slaac@ietf.org
References: <3A94E3B6-EA5A-453A-8CB1-C11BBDF88B53@gmail.com> <CAD6AjGTcy3eo=4P52fOjCKRLDveVMUJcD7Y_u9JzJtpq3RAj0Q@mail.gmail.com> <636E07D5-2554-40A7-9C3B-C699EA29BD52@isc.org> <CAD6AjGSnw+DG+sDb1ddHVudZdHsGWcN+8GgJd2DKrqpBG3WWUg@mail.gmail.com> <61D91FAE-C7AF-48E6-AE90-638F92E4EB35@fugue.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <4e015b11-bdad-b719-2af2-015d949f0764@joelhalpern.com>
Date: Mon, 09 Nov 2020 23:27:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <61D91FAE-C7AF-48E6-AE90-638F92E4EB35@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GCIvLrPLrmR5b84eYbq-aaX19EM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Nov 2020 04:28:05 -0000
Ted, I'm not an operator, but I sure find that a very dismissive response. (I doubt that was your intent) There are operational complexities to adding a new kind of server into an operational network. (Side note, we are in this case not talking about the IT department. We are talking about the operational efforts of an ISP.) When operators tell us they have constraints, it is fair for us to inquire as to the nature of the constraints. It is not fair for us to say "you MUST make different operational choices." We as a community decided that there were going to be two paths to operating an IPv6 network. (SLAAC and DHCP, let's not worry about other corner cases.) When we made that choice, we should ahve recognized that there were operational implications, complications, and trades inherent in that decision. Just as we need to (and usually have) listened when operators have asked for DHCP capabilites that they need, we should be listening when operators tell us there are RA / SLAAC capabilities they need. In particular, Cameron has been very forthcoming and clear about what he wants to deliver and what his operational constraints are. Implying he should just use DHCP anyway seems an odd answer. Quite a number of us have said over the years that we want operators to participate more, and we want to understand what they need. We may or may not decide to make changes (listening does not mean agreeing). But we really should be paying attention to what the range of operators are telling us. I hope that my notes to Gyan have been questioning and done dismissing. Apologies if they have come off otherwise. Yours, Joel On 11/9/2020 10:31 PM, Ted Lemon wrote: > On Nov 9, 2020, at 10:15 PM, Ca By <cb.list6@gmail.com > <mailto:cb.list6@gmail.com>> wrote: >> The force required to break the current stasis is more than i have, if >> i must use dhcpv6. Again, many years of proof. > > So, to summarize, the problem is that you can’t get your IT department > to install DHCPv6 servers? > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- “DHCPv6, SLAAC, Static Day X - 17 year interopera… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Joel M. Halpern
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Ca By
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Mark Andrews
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Joel M. Halpern
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Joel M. Halpern
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Mark Andrews
- Re: Re: “DHCPv6, SLAAC, Static Day X - 17 year in… Michael Richardson
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Ca By
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Mark Andrews
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Ted Lemon
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Joel M. Halpern
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Mark Andrews
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… JORDI PALET MARTINEZ
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Mikael Abrahamsson
- Re: [**EXTERNAL**] Re: “DHCPv6, SLAAC, Static Day… Mudric, Dusan
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Alexandre Petrescu
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Joel M. Halpern
- Re: Re: “DHCPv6, SLAAC, Static Day X - 17 year in… Gyan Mishra
- Re: “DHCPv6, SLAAC, Static Day X - 17 year intero… Alexandre Petrescu