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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 November 2017 00:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 357E512EAFA for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 16:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1mT1AyiinB_V for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751B8129A9D for <ipv6@ietf.org>; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id p9so8755367pgc.8 for <ipv6@ietf.org>; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CKZc8dVi4yOBpXs5l1iEQavcbsHJTvAernn9i3F4TyQ=; b=W6Q6PQO6qMaeZSpyrzcwjsDRn8hZG0qXns2vCSITtDzyC6pGHxikfFdf/as+RSv4Pk fZJKe+TMpfKZhWuwypbbvbRRr/b0kKDo8a2Rgs7ipskfnL3eQQzu7TsGjXhDubbQ7/aR idO2C0y5xeWNi7kIsA+edzyVf1nq1kbqLNZ/iYDo0ru2iBqPpO6ZVP2pilR5T1zHukG/ bQqFF6Vod7/ildOiUnGm2I81cyxOwd1nkEwTUtfBomzcyZFkHclTitWAOa2FccHxTHoZ KQYBHG9HNOlJ3XHyWIItlJs2TicSa3vJVs89l2GXSQu/oUuABsZlpvXi3e6G1qY4hYXZ 5s2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CKZc8dVi4yOBpXs5l1iEQavcbsHJTvAernn9i3F4TyQ=; b=lSNwlpb7ehLB3T6PYcKEzCN997Q2kVcPHPHgn3QfzDoDb6zNuaVISdBb7sp0CsuQXL qk4HAGelLKlh/1UVRs6SnJwJGyc7Bg+8v9LIbVrl9xBjNWmkbps3xstS1c7uYycxYO7k nYqf2zXJl/turhTNUp3QhHkBamuZJTYIvRX/UvNl6493OqnIiiL7eicGURuRtsDGQouY vs87SDIl98IEKkmXCYH+IAbkKNaX2h2PdBW5cW5sevQI2m+8oNa3QFq7S6OUwu3pkXxS /suGX1K7TSylXVlDZDF7cfTCzUCKkQukp/kVPm+qPqxaz26KO1z8YAo6wBVtY2PltmP/ /KMg==
X-Gm-Message-State: AJaThX4RXZA0R8gJ6yTW+0Ax2LOgMqkyCOrd2BS5UyVbmI0Ofq4sxR5F pHocJ7xgkA/rwgz8u16Ok9AdUg==
X-Google-Smtp-Source: AGs4zMa23UeHZopIKup08TvYDGw/oM6Aw+pa8jteAOcnRUt8lxam5pg6MJcgy2Y7+6aEVqDa6zgIuw==
X-Received: by 10.98.161.25 with SMTP id b25mr13232861pff.103.1511224799720; Mon, 20 Nov 2017 16:39:59 -0800 (PST)
Received: from [172.24.41.18] ([202.36.244.186]) by smtp.gmail.com with ESMTPSA id w20sm23336227pfi.89.2017.11.20.16.39.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 16:39:58 -0800 (PST)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com>
Organization: University of Auckland
Message-ID: <01ba0acb-0528-a6b9-8830-e5d1d44de6c2@gmail.com>
Date: Tue, 21 Nov 2017 13:39:56 +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: <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-Q2GHmdIHRTqTUrUX9adq3jveA0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 21 Nov 2017 00:40:02 -0000

Hi,

This time, not truncated by fat-fingering.

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? :-)

>     [2] I would not say that 0 means "IPv4 is Available on this
> Router" but rather "this router makes no attestation about the
> availability or lack thereof of IPv4"

I'm not sure.  It doesn't really matter, because it's only when
there are no unexpired RAs with flag==0 that we switch off IPv4.
So the only assertion that matters is that flag==1 means "I don't
route IPv4, but I don't know what other routers do."

> 
> there would also be a SAVI implication here; otherwise any connected
> host on an l2 domain would be able to disable ipv4 on any host that was
> listening to a flag of this form.

No. As long as at least one unexpired RA has flag==0, nobody stops
trying IPv4. A bad actor can send as many flag==1 bogons as it
wants; they will be no-ops.

    Brian