Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 08 May 2019 05:54 UTC

Return-Path: <swmike@swm.pp.se>
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 2BE5012008C for <ipv6@ietfa.amsl.com>; Tue, 7 May 2019 22:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=swm.pp.se
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 GxRV5jpsv-AG for <ipv6@ietfa.amsl.com>; Tue, 7 May 2019 22:54:25 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 35C4A120086 for <ipv6@ietf.org>; Tue, 7 May 2019 22:54:24 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9852CB5; Wed, 8 May 2019 07:54:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557294860; bh=/1Ff3EApYCvsH97/8KwwW2yHyGr7oBg92zreKvswSy8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vVS38/woAxELQBzyBIcuy5SLVy1lqKrra782lGAQwamKZdt6/+LHBviV89kJ5iiIl c52oSmQnZILXRGmLRktbfrEnSEV8leLDL/uRYo3O7s3U08s6NQLbdk3CxgiDRfJQU8 +XtOZSkoaYXF2xCx1Gl9kfoKCPCFwXPDliksT19U=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9424EB0; Wed, 8 May 2019 07:54:20 +0200 (CEST)
Date: Wed, 08 May 2019 07:54:20 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Nick Hilliard <nick@foobar.org>
cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <478d5dc5-af00-4ab0-d8ef-75e41cd501d4@foobar.org>
Message-ID: <alpine.DEB.2.20.1905080741560.1824@uplift.swm.pp.se>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <a2465e81-a17f-ab48-efda-20fe12a70077@foobar.org> <30239E0C-C444-4A7E-8342-AEE47BF8A2BB@employees.org> <20190505200449.GB7546@vurt.meerval.net> <80073906-c3c0-1f22-9e7f-c2b349063936@gmail.com> <CAO42Z2xzVW3m0mN7jEn8SYyYCYhrufVnkfp3rBjJcijBkvucNQ@mail.gmail.com> <CACWOCC-35yVYXSRR0sRL-MBMHyOFZtJx9E9h14G8qqVh5T7qGA@mail.gmail.com> <232c1a43-0fd9-4eae-737b-260a3906f72a@gmail.com> <51F2BD2A-A590-4AF1-B8C1-FE62C9416340@steffann.nl> <8C63324F-FEF6-40BD-B918-B413CDEF9186@gmail.com> <478d5dc5-af00-4ab0-d8ef-75e41cd501d4@foobar.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hw7miQMQs5ZuUh-EGOt09bUB1wM>
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: Wed, 08 May 2019 05:54:29 -0000

On Tue, 7 May 2019, Nick Hilliard wrote:

> But here's the thing: if they already have to change the default 
> configuration to enable v6only, why wouldn't they go the whole hog and 
> just disable v4 completely?  More to the point, if they need to delve

Because in a migration scenario you might have years where the device 
might move between a dual stack environment and a single stack 
environment.

Having a signal from the network at each attachment point what to expect 
would be nice...?

Anyhow, my take from speaking to a few host stack implementors it seems to 
me they'll take this flag as a hint initially and as the future slowly 
progresses it'll become more and more "authoritative" if it seems to work 
well.

As for the security related objections, I just think they're completely 
irrelevant. If you allow unauthorised RAs on the network, you're screwed. 
Screwed. There are so many other ways existing RA mechanisms will screw 
you from a security POV, that this IPv6-only flag is just added background 
noise to the threat model.

The host stack vendors don't trust what the network tells them anyway, not 
without verifying. So at attachment they'll run connectivity checkers 
(does this give me Internet access? Captive Portal?) so they'll just plug 
the state of this flag into that machinery and check and verify, and would 
probably use the flag to do more exponential backoff on trying IPv4.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se