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
> --------------------------------------------------------------------
>