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

Brian E Carpenter <> Tue, 21 November 2017 01:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3D821242F7 for <>; Mon, 20 Nov 2017 17:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjWOqXSxjfQu for <>; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B808124217 for <>; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
Received: by with SMTP id 17so8653067pfn.12 for <>; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BxhFkL4Zgi4evhIWj0matdWiqLQ6GQr1GPrenwoLaAA=; b=UMJMFBc4Y5TVNe+v950XNfev6CaD3j9DmeHt9YoC9YhG2kr+Y+izn9WQVEmO9Hcdsh N3RRkyxMPn8nw/POQ+rJdaTmONsvVhnG5k2JIupjurli4UmO1Vi7CQDwQDC+ubCulmB9 CrZEWPwSFxWMhj/3T+9bjsc54ltQhArwV/hKFq3FeOraTrcWwyc+PoXUk7ozfcuKJAE+ spfZyyJmuFaj1f784FnSx/xaEy6G6/6+D9ngpjk5SPbZ5OhOuYCKfnF0c3YgapwucmMm MqTkEw+C7UUGQmyqlzTZr7ue1A32sKZyOQQKUi5EXDcT8RGir7zxVkycVcohzmeVph2f sjKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BxhFkL4Zgi4evhIWj0matdWiqLQ6GQr1GPrenwoLaAA=; b=cLdpJ9qUTHV7yOPfJUc49ff5NsCWbgQOr8LK2tNiryzDGEIZPok69VJeuwngIFA7xI oriYix8I5LcwEBFr7/hS9jGc/4kLesELWPI3yx3Oe2jzTkvpvbYlcnYh7a0PIOeRn6Th JjwwvtisnAv5PiO8DG3+mHDNyrs/MxJDmBkNlXo0/sZ4W8bZeqgvm40wT/f1kVECXBq8 PnEfrfYbpOAXcJy0G/l3Z/Spg93chSEGyCribcWVfMPXTTeLFJY356IAoZLzwN7m0u3W xGq9IIUs5rsyh02GO1c3TQOU50MaLHULqbV9FFFwTXl4U//U9JgRII9RSU6RejyCssff b60g==
X-Gm-Message-State: AJaThX5kWapZeYbLTuXwX8+LIwBfic7ENvCS2yXb9aCfDaKcajx9kpFH BD0Jtwwcn0tIZTcHGyR5jxzT/g==
X-Google-Smtp-Source: AGs4zMb6+sqx4xB3ZKp8irlLgODt6mPquJEhg54FwD10qi54hQLSulImnLTY4W2X7k1zDLERxPHVqw==
X-Received: by with SMTP id j2mr15578424plt.7.1511228548161; Mon, 20 Nov 2017 17:42:28 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y20sm20862251pgc.52.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 17:42:27 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 21 Nov 2017 14:42:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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: Tue, 21 Nov 2017 01:42:31 -0000

Another response to multiple points:
> If people really care, they should just program the local routers and switches to block the IPv4 related multicast traffic. That will be much more direct than a bit in some RA.

Layer 2 or layer 3 blocking is fine, but it doesn't help
the battery life of the dual stack hosts.

> How about a transition rule for dual stack implementations? If there is IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify that rule with availability of a 6to4 prefix?

I really hope you didn't mean "6to4". But that heuristic will only help
if all apps are IPv6-capable, which the IP stack cannot know. (It also
leaves IPv4 literals out in the cold.)

> 1. Security exposure; the inverse of the problems discussed in RFC7123,
> basically malicious or accidental IPv4 service.
> 2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
> IPv4-LL, ARP, service discovery, etc...

The proposal addresses only one thing: attempting to reduce
futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

> In very high dentistry and therefore
> typically congested WiFi environments...

A new view of dentist's office networking ;-)

> Probably the best that can be done by the client is to be "less aggressive" in trying to configure IPv4 when IPv6 is available and you don't seem to see IPv4 traffic from other nodes.

Indeed, but that's mainly an implementation choice. This proposal offers
a hint to assist that heuristic, if you like.

> Let's not forget about battery life.

Agreed. Every little helps.

> It just seems operationally simpler to create a new option in dhcpv4

I don't see how that works on a network with no DHCPv4 server.

> if IPv4 appears you probably want to start
> using it after a reasonable amount of time.

Indeed. And under the proposal, any RA with flag==0 would be
an instant trigger to wake up the IPv4 stack. (And no, that
isn't a serious DOS risk, since it is no worse than what
we have today.)