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

Brian E Carpenter <> Tue, 21 November 2017 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CC9F12EAFA for <>; Mon, 20 Nov 2017 16:29:40 -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 dfxpxYuNk39v for <>; Mon, 20 Nov 2017 16:29:38 -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 6ED5812EAF5 for <>; Mon, 20 Nov 2017 16:29:38 -0800 (PST)
Received: by with SMTP id r88so4593514pfi.2 for <>; Mon, 20 Nov 2017 16:29:38 -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=+iUJ4EhZz+BB5Y3cpZGIEm7J4x8XlWBD2Wb/4oC2D7E=; b=IFIjXA1257vYz5qvAks/AZXc5lDY6QI6ymPpcWyG0Lgc0jhDD7o+yssVeplOcAiwGh m2iFHrOcAzAaXZ+VWP5tpljlijkzdxrAgWSbIs7gVDe2hETMorP4ZHRubUEU2le9WM8L CO+lU7VSOmHnM4XczJ/o7FuoClAR+TXqMZUkCdz7I1HulxoLFGQnUsijzGPIIuJNVYxQ 5QAnJBDYGrz2P4Uhfwc2nJj/sYyeudhiurTi7oH0EjlvYB0qFF/8neRBiIhG0N6SPbjH EOgHPzIPFmTrToNj/5WRhqW0byC98DoHBL0lVu5gUGyJWu5g3vz9iBk5Mc+2/2/BCXAv da1A==
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=+iUJ4EhZz+BB5Y3cpZGIEm7J4x8XlWBD2Wb/4oC2D7E=; b=ZiQjk1QHXlpHdMPyNFJIZ2/JBAbOjZz2S+/PfvlnPYDpmtKkOGfFJmEuBMyQr7bb2Q L0MB6/5GdQNWIje4fxaacXK/2Ck/RUSSDTtCDpKRJV0aa0QvAfqbn7GFUkxTBazXRTzV rDr3clNhePkRPbWzsCKmr1U0RBl98uXB9jfrDcmic7A2JKKwOk53cKHPQ/WVIflI5sjP rxdeGQMOPEPh8nClPCu7aF0vk8/T6BviHEngj4lMgXRom6q3Pg8wk9ZyjPElKMSXrLzn wAaj+CWVxf9pHPuoYudUYHdIf6cEYHL7jx23woyUTyiM63ly+322KEc3CP+CesVPhnuR Hsuw==
X-Gm-Message-State: AJaThX4VJGMNHG1hoUlF1JvZGbcsKvgzDRlmbCnTCZgxUP9cXacyseAS T+MjT0UBN94gRlLvhrCZwPCrbw==
X-Google-Smtp-Source: AGs4zMbp+qgJr5pAfTjI7VD8IgvfdvNzo+VvFIuxXFZ8GHW/ppzc7kMul8UY/FN2NOiRvleHh8h8Jw==
X-Received: by with SMTP id t10mr909728pgu.335.1511224177476; Mon, 20 Nov 2017 16:29:37 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t2sm23830741pfk.90.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 16:29:35 -0800 (PST)
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden <>, IPv6 List <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 21 Nov 2017 13:29:32 +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 00:29:40 -0000


Here are some consolidated responses to a very long thread:

> draft-ietf-sunset4-noipv4

Sorry we were unaware of that. I think that a new look at
this approach is needed given the increased experience
that we now have. But at the very minimum our draft
should recognize the earlier work.

>  If the
> meaning of the flag were modified to indicate that there is either no IPv4
> service on the advertising router, or that any IPv4 service provided is
> intended to be limited to only hosts needing it for backward
> compatibility... what I'm proposing allows a limited scale legacy IPv4
> service to be provided instead of a full scale IPv4 service.

I think that semantic ("we have IPv4 but please don't use it") is
unlikely to work in our dog-eats-dog Internet.

> I also suggest a "Host behavior" section be added.

Good idea.

> I’ve the feeling reading your proposal that you’re assuming that the dual-stack hosts have the transition mechanism built-in

That's certainly not my intention. Cellular networks are different,
but in a general-purpose network, classical dual stack hosts is
the only safe assumption. We should clarify the document scope.

> - this is a trivial DOS if there is really an IPv4 network

Any single occurrence of flag==0 says IPv4 is available. Any number
of flag==1 does not change this. So this attack does not exist.
>   — "A host that receives Flag=1 should stop sending IPv4" 

Yes, that is wrong as a stand-alone statement; it needs to be
qualified (in the simplest case, "only Flag=1", but it needs
to refer to unexpired router lifetimes, so more words are needed.)
> So, no… we’re not going to stop sending RA messages (lifetime=0) . And so, we’re going to step on this 4=1 bit until the end of time. In other words, this draft won’t do what it hopes to do.

So who is defeating the intent of the existing standards there?
OK, maybe we'd better not have that conversation. We'll think
about whether special-casing lifetime==0, but the solution is
fail-safe: even one unexpired RA with flag==0 will override any
number of flag==1. We will never switch off IPv4 in such a case.

> Yep, a single flag won't work unless all routers agree on it.

That's a feature, not a bug. That's why the proposal is fail-safe.

> It would be up to the administrator to ensure that no router sent the
> option unless the network were truly IPv4-only.

No. It's router-by-router, so *all* routers must send flag==1 to
change host behaviour to IPv6-only. Default host behaviour is
dual stack.

>     [1] I would propose making it an EFO bit and leave the reserved
> bits for potentially more IPv6-critical information signaling.

Don't you think that switching off IPv4 is IPv6-critical? :-)