Re: DHCPv6-PD is fine
Havard Eidnes <he@uninett.no> Mon, 09 November 2020 21:00 UTC
Return-Path: <he@uninett.no>
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 4999B3A1360 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 13:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=uninett.no
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 gaP6F27tneO7 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 13:00:39 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110123A135F for <ipv6@ietf.org>; Mon, 9 Nov 2020 13:00:37 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 0B39F43EB2E; Mon, 9 Nov 2020 22:00:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1604955635; bh=1E09op2KbycLdSMEd8sEORpoYkZ3OAYU+/zLvQhJvJc=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=plutTZh6a1g74CMMJN2bLoEfR7lCth17AZ19RmgLOCJu47G/+nKp3+zLn4E7pmOOg FV5BzBw8mdX/BgB8wp9wrQKDmNM7t4SJsZD7CYKzTvBaNRJfLAT5//+Eny0Yl7j1Aq 6iyac97Gavjt8Ehhfd3l5DWHpXKRerBJSSLYeNuw=
Date: Mon, 09 Nov 2020 22:00:35 +0100
Message-Id: <20201109.220035.1460667476695106090.he@uninett.no>
To: bs7652@att.com
Cc: linux@thehobsons.co.uk, ipv6@ietf.org
Subject: Re: DHCPv6-PD is fine
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <SN6PR02MB4512DE7BF31D8758BE15D899C3EA0@SN6PR02MB4512.namprd02.prod.outlook.com>
References: <350919b2-fe50-a3b8-3f15-4ce32124d495@gmail.com> <3377F3AE-BDFE-4AAC-ACA3-0F3D1A4D8854@thehobsons.co.uk> <SN6PR02MB4512DE7BF31D8758BE15D899C3EA0@SN6PR02MB4512.namprd02.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hTvjFjcAjN5C7c8i8mSRNVQYcwg>
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: Mon, 09 Nov 2020 21:00:42 -0000
>> From what I've been reading in this thread, in the mobile >> world the problem isn't DHCPv6-PD, but the cellular world >> having not adopted it, or even blocked it (ref discussion of >> mobile modems blocking DHCP packets). Is this lack of flexibility for all intents and purposes imprinted into silicon? That would ... be an extremely effective road-block for practical deployment if one wanted to make a change where DHCP should additionally be used. >> For clarity, is there a problem with DHCPv6-PD, or is there a >> problem with the mobile world not supporting it for whatever >> reason ? >> >> The reason I ask is that if it's the latter, then the response >> to "it doesn't work, we need to change something" is that you >> need to go to the mobile industry and tell them to fix their >> ****. > > Please don't take this personally, but, IMO, this is exactly > the attitude that has brought us to this point. The IETF > participants think IETF is in a position to dictate and think > they know better how to operate and deploy a network than the > operators. An alternative perspective could be that the mobile industry collectively refused to cooperate for "whatever reason", and now come back at the IETF without in detail explaining why DHCPv6-PD "didn't work out", but instead want new protocol development to essentially solve the same problem in another manner, using a different protocol? We all here know how enthusiastic the IETF is in solving the same problem with multiple protocols, ref. the long-standing controversy over address configuration in IPv6. Also, I don't think it's entirely unreasonable to claim that the IETF controls the development and standardization of Internet protocols done through the IETF? > Availability of equipment that implements features, complexity > of legacy OSS/BSS systems, and complexity of deploying multiple > methods of configuration (to make everyone happy) are 100% > irrelevant and operators should simply spend whatever amount is > needed to do exactly what IETF dictates. Now, now... Imagine for a moment that a new protocol or protocol variant was developed and standardized through the IETF for handing out larger address blocks to customers. How would deploying that imagined new protocol be any easier with respect to the above mentioned complexities or obstacles than doing the same with an already standardized protocol? (However, if DHCP is in essence "blocked by hardware", that makes that avenue for all intents and purposes unusable in that particular use case. Not sure I'd blame the IETF for that one, though.) Or .. I may not understand what you are saying here. Are you implicitly saying that "This isn't a problem worth solving" or "This problem costs too much to solve now"? I think I'm confused. > I've suggested engaging and collaborating with other SDOs where > operators prefer to do their work. But that suggestion clearly > has no support here. Building organizational-level collaboration and the needed mutual respect, and overcoming the obvious cultural impedance mismatch is decidedly a two-way street. I'm not sure it's fair to put all the blame on the IETF here. Regards, - HÃ¥vard
- DHCPv6-PD is fine Templin (US), Fred L
- Re: DHCPv6-PD is fine Alexandre Petrescu
- Re: DHCPv6-PD is fine Templin (US), Fred L
- Re: DHCPv6-PD is fine Simon Hobson
- RE: [EXTERNAL] Re: DHCPv6-PD is fine Templin (US), Fred L
- RE: DHCPv6-PD is fine STARK, BARBARA H
- Re: DHCPv6-PD is fine Philip Homburg
- Re: DHCPv6-PD is fine tony.whyman
- RE: [EXTERNAL] Re: DHCPv6-PD is fine Templin (US), Fred L
- Re: DHCPv6-PD is fine Havard Eidnes
- Re: DHCPv6-PD is fine Templin (US), Fred L
- Re: DHCPv6-PD is fine Ted Lemon
- Re: DHCPv6-PD is fine Havard Eidnes
- Re: DHCPv6-PD is fine Brian E Carpenter
- Re: DHCPv6-PD is fine Alexandre Petrescu
- RE: DHCPv6-PD is fine Vasilenko Eduard
- Re: DHCPv6-PD is fine Alexandre Petrescu