Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Fri, 02 November 2018 10:05 UTC

Return-Path: <bzeeb-lists@lists.zabbadoz.net>
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 1ED0A12D4F2 for <ipv6@ietfa.amsl.com>; Fri, 2 Nov 2018 03:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 gXnrzm7FIfsE for <ipv6@ietfa.amsl.com>; Fri, 2 Nov 2018 03:05:46 -0700 (PDT)
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8451288BD for <ipv6@ietf.org>; Fri, 2 Nov 2018 03:05:45 -0700 (PDT)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6DF428D4A217; Fri, 2 Nov 2018 10:05:40 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A354BD1F865; Fri, 2 Nov 2018 10:05:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id KIu0qGfa_SWr; Fri, 2 Nov 2018 10:05:36 +0000 (UTC)
Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AAE79D1F84D; Fri, 2 Nov 2018 10:05:35 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To: Lee Howard <lee@asgard.org>
Cc: ipv6@ietf.org
Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt
Date: Fri, 02 Nov 2018 10:05:34 +0000
X-Mailer: MailMate (2.0BETAr6125)
Message-ID: <07D3463F-963B-4BDA-9109-946824DF25E9@lists.zabbadoz.net>
In-Reply-To: <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org>
References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <CACWOCC-xL0PfkNHgCqhB28GE-jCWUUagQE4PukdpXK+YHgWpyg@mail.gmail.com> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KFAgPBBBrfU7qeEidwSBQIj4OoY>
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: Fri, 02 Nov 2018 10:05:49 -0000

On 2 Nov 2018, at 6:09, Lee Howard wrote:

> Doesn't it mean that user space applications on a host that 
> had/expected IPv4 would fail?
>
> I think I described my interop concern: 
> https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm
>
> IPv4-only hosts, and dual-stack hosts
> that do not recognize the new
>     flag, may continue to attempt IPv4 operations
>
> If some devices require IPv4 and others disable IPv4, you have lost 
> connectivity between systems on a local network. As written, this is 
> not considered a misconfiguration by the administrator who sets the 
> flag.

The draft says “
    Dual stack hosts that have a good reason to use IPv4, for example 
for
    a specific IPv4 link-local service, can attempt to do so.  Therefore
    respect of the IPv6-Only flag is recommended, not mandatory, for
    hosts.

    Administrators SHOULD only use this mechanism if they are certain
    that the link is IPv6-Only.  For example, in cases where there is a
    need to continue to use IPv4, when there are intended to be 
IPv4-only
    hosts or IPv4 routers on the link, setting this flag to 1 is a
    configuration error.”


And heck, if user space applications fail because v4 doesn’t work 
anymore, than they work based on an assumption (and have been for 20 
years) and they’d better get fixed.

Here’s how it goes: (a) network admin turns ipv6-only on, 98 of 100 
hosts are fine;  2 hosts with their secret covert channel no longer talk 
for some obscure thing interacting on the local network only.  (b) users 
panic looking at their “very important service” (e.g., their private 
chat protocol written out of boredom at the end of 1999).  (c) admins 
shrug and move these two machines into a quarantine network where they 
can still talk ipv4 and will be (1) running forever until the hardware 
dies, (2) until someone fixes the software to use ipv6, (3) for the next 
6 months until the vlan is decommissioned.

The answer is: if that service is critical you will (A) be happy you 
found out about that problem if no one knew about it before and (B) 
you’ll do everything to fix it in a good way (and that could also be 
to disable that flag for another two weeks until everything is sorted).  
But you’ll fix that software.    If it’s not relevant it goes into 
“collateral damage” and you are happy that the thing is gone from 
your network and your “network hygiene level just went form orange to 
green”.

I’ve played these games for more than 8 years.  And you have to play 
them a lot less these days compared to 2010.

I guess it all depends how you arrive at the day to “turn the 
IPv6-Only flag on”.  Ideally you have selective removed IPv4 from the 
network before so the flag more or less ends up to be just a “OK, this 
is IPv6-only so make sure it stays that way” for where you have 
critical services.   But this is all “ops” and not 6man.


>>> This also disregards the issue of whether the flag was either 
>>> necessary
>>> or a good idea to start with, and nearly 700 emails into this
>>> discussion, the WG seems to be hopelessly divided on these issues.
>> I'll leave that one to the WG chair who isn't a co-author. But I will
>> say that in my mind the issue is whether the feature is one that will
>> be valuable in 5, 10 or 20 years time rather than whether it's 
>> valuable
>> today.
>
> I've come into the camp that believes that in 10 or 20 years IPv4 will 
> be disabled by default. When people post to stackoverflow complaining 
> that their 10-20 year old devices are unreachable from their brand new 
> devices, the response will be, "The old stuff might be using the old 
> protocol, IPv4. Go into Control Panel, Networking, Protocols, select 
> IPv4, click enable."

Very much like people posted “My token ring can’t talk to my 
ethernet?”  Look in 10 years the IPv4-only Islands will be very much 
understood.  People will be looking for “migrating” these to 
“something entirely new”.


> If that's likely, then this flag is only useful in the interim 5 
> years. During that time, I would like to maximize connectivity.

The flag will still be useful in 127 years when people will do IPv9 and 
there’ll be people around who say “This IPv9 stuff I am not going to 
touch, keep this legacy IPv6 on until everyone else in the world has 
moved.  Then I can go and look.”


> If a network administrator wants central control over IPv4/IPv6 
> enablement in hosts, there are better, more centralized tools for 
> that. As a principle, host behavior should be managed by host 
> management tools, and not by hints from a router.

Or by hints from a central directory service?  I guess it’s better 
I’ll remove your host entry from my dhcp server as well immediately 
then.  And also stop answering ARP and RS for you.  You can configure 
that using your host tools.

/bz