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