Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Nick Hilliard <nick@foobar.org> Tue, 21 November 2017 15:47 UTC

Return-Path: <nick@foobar.org>
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 9682D1294F3 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 07:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TOD28xsDjlNP for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 07:47:44 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7225B1294E2 for <ipv6@ietf.org>; Tue, 21 Nov 2017 07:47:07 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vALEkqdT074799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2017 14:46:52 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A144A78.6060108@foobar.org>
Date: Tue, 21 Nov 2017 15:47:04 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com> <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <CAKD1Yr3WC+vwL_=0PeiJ_D85NqFVTCkb8c83x-ZtGhAbSELGMA@mail.gmail.com> <5A119443.2030108@foobar.org> <CAFU7BASwgLfkO-4kk9-vba_P+jmcFHD5+Hy_7b3cnNkOSv30wg@mail.gmail.com> <CAKD1Yr3pKk22Hkxy4_8YMZYiA4Wwp=6JzdRDKFGdTY1gf=ntfA@mail.gmail.com> <alpine.DEB.2.20.1711200848390.32099@uplift.swm.pp.se> <5A12FBE4.9030101@foobar.org> <alpine.DEB.2.20.1711210647151.32099@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1711210647151.32099@uplift.swm.pp.se>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SDGMv8k-H1bDsz_RYTqhxTRy7xg>
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 15:47:47 -0000

Mikael Abrahamsson wrote:
> Indeed. And I'd rather put this hack in IPv6, as it requires adding code
> to configure and send an additional RA option compared to requiring a
> complete IPv4 stack and DHCPv4 code to send some option there.

I agree it will simplify things on the operator side, slightly.  The
complication on the client side is substantial though, and it's usually
the client side where we run into deployment problems due to high levels
of heterogeneity and in this case, layering issues, i.e. using ipv6 to
signal to a kernel which needs to message-pass to a dhcpv4 userland
process to stop issuing queries on a specific interface or to otherwise
implement what we mean by this flag.  There would also be a requirement
for the network edge to be able to filter out RAs with this option,
given that the ipv6 / RA model is to be able to deploy multiple routers
and we cannot assume that this flag would be limited to e.g. cellular
networks or resi access networks or whatever.  This added complication
is why I question the wisdom of the RA approach.  Simple, even if it
doesn't solve everything, is usually better.

Nick