Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
From: Mikael Abrahamsson <[email-masked]>
To: Nick Hilliard <[email-masked]>
Cc: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Date: Wed, 8 May 2019 07:54:20 +0200 (CEST)
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>

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: [email-masked]