Re: New Version Notification for draft-hinden-ipv4flag-00.txt

Simon Hobson <> Sat, 18 November 2017 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34AD4126D3F for <>; Sat, 18 Nov 2017 03:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YyYDauPzsH2D for <>; Sat, 18 Nov 2017 03:10:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EB3712025C for <>; Sat, 18 Nov 2017 03:10:28 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at
Received: from simons-macbookpro.lan (unknown []) by (Postfix) with ESMTPSA id C8AC11BC37 for <>; Sat, 18 Nov 2017 11:09:36 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: Simon Hobson <>
In-Reply-To: <>
Date: Sat, 18 Nov 2017 11:09:25 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: IPv6 List <>
X-Mailer: Apple Mail (2.1510)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Nov 2017 11:10:30 -0000

Lorenzo Colitti <> wrote:

> What about an option that signified there was no IPv4 on the network? If the option is sent by any of the routers on the link, then hosts would not attempt IPv4 configuration.

Doesn't that come with exactly the same problem as described ? If *ANY* router on the network provides IPv6 only, then it'll signal that there's no IPv4 on the network even though there may well be. Since that router may or may not actually provide full connectivity, and even if it does it may not be what the network people want devices to be using, then the end result is "device sends RA, breaks network".

> Not sure how that would support IPv4 becoming available once the option has been set.

Presumably the device would stop signalling that there's no IPv4, and then it's up to the hosts to decide if they will try configuring it.

> Also, not clear how to deal with the DOS scenario where a rogue RA disables all IPv4 on the network until the end of time.

That's not really a new threat. A rogue device can issue RAs and make itself the default router and break IPv6 - so the only new aspect is that it can break hosts that do try connecting via both IPv4 and IPv6. Looking ahead to the final destination of having no IPv4, then the end effect is the same - a rogue device can use RAs to break the network.