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

james woodyatt <> Sat, 18 November 2017 02:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97B23120721 for <>; Fri, 17 Nov 2017 18:20:08 -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, HTML_MESSAGE=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 FrESjnLQzhsA for <>; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54470124E15 for <>; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
Received: by with SMTP id z184so3237922pgd.13 for <>; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D9Kl613onYl3nrYiYz2yaZ8BHRvHZyaFu/CHoNhXVfQ=; b=NEUTU8OUTYs9JZ+CwCocQC4USMUM8kBFKtffLSIKWFtGi1PPUBdAMKqFfkz3I/MXRc IBc/cydIlk2mGCY7gr3oo+vMLJbmj39YqQi6dBDhIk1Lw+bbHUWz+rwK2+PqL5XtX1B8 84//RDNkSE3G/rYjQedvnnPTJ91sBDJwQY8i4ibj23Y04kcZkz3Iajyw6X/XPWwHXRa4 Wyr5E/ihsp+HBbwqO8VLP4UZOy4pvix5E6B6j8I4ODr595s977B57HHjevWlMeu6Sy1K EIFgfGigosndJI9s9llxwo4QnwrTr5b1Lrz9kGG7Af5KbgfNi9GIxQNHE2Pd/A6P4Eze k4pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=D9Kl613onYl3nrYiYz2yaZ8BHRvHZyaFu/CHoNhXVfQ=; b=Ryyjdlg32mZjUGRC4nuWZVGRH4Q1ShVdN+G6P+1nyeau04w8g075MLKorF4w5zZqzb Bfa6TE2r6daQc2Q7iITdDbiEBJzOhslH2g7TioLhj1XybSZsKDutPkVDg8kQ0HeDkKwz 2AM21o2yOI45lR95aNDeFnaYQl4e0dA/i9QIREIXwMA+sGz8smACu+EP7z5le7pGWWri PyuDLIfgjtD31v2oVOapzzOsY2SZxKWalDto6laBcCK6IglbxbnT7KT7J0J1UScyHT74 4PaCouXX6IcX4604ljJ2ucaeVzTyO+a+KieT7YfdlKU5ifQTwe56zFOiLzz7k6gnykOB Raxw==
X-Gm-Message-State: AJaThX6k2jiRvGNjFiORqtpQQ2aAP2m2shXBsHu6kiCS+apao8g/6hlX U6ApBksDwsEtYQ6cduFwf6LBJLUvWAw=
X-Google-Smtp-Source: AGs4zMaa8fvBhS+s9/u5mWH6MkzmPlnmGaGyVw38Jj6ALvuZhczIJgg3eSKz7QFoYxoApbKu9ZCAEg==
X-Received: by with SMTP id n65mr4028020pfh.113.1510971605512; Fri, 17 Nov 2017 18:20:05 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:59c:dedc:46fd:69d4? ([2620:0:10e7:10:59c:dedc:46fd:69d4]) by with ESMTPSA id v28sm8888324pfl.118.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 18:20:04 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5511B676-3343-4C93-A2EB-0AA97E7EA758"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Fri, 17 Nov 2017 18:20:03 -0800
In-Reply-To: <>
Cc: Fernando Gont <>, IPv6 List <>
To: Bob Hinden <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
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 02:20:08 -0000

On Nov 17, 2017, at 15:31, Bob Hinden <> wrote:
> On Nov 18, 2017, at 2:39 AM, james woodyatt <> wrote:
>> On Nov 17, 2017, at 00:17, Bob Hinden <> wrote:
>>> The flag is to tell the host to not use IPv4.  Once the host see the Flag=1, it should stop sending IPv4.
>> The draft is very confused about what the flag means. And both of the conflicting descriptions in the draft are in conflict with this statement. Here are the three conflicting positions (I’m wondering how many will emerge before this can be sent back to the April 1 queue).
>> — "IPv4 is Not Available on this Router"
>> — "A host that receives only RAs with the flag set to 1 should not attempt IPv4 operations, unless it subsequently receives at least one RA with the flag set to zero."
>> — "A host that receives Flag=1 should stop sending IPv4" (to what routers? on which interfaces? until what condition arises?).
>> Please send this draft back into the For Comedy Purposes Only category and leave the serious business of this topic to the SUNSET4 working group, which is actually chartered to deal with it.
> That’s harsh.
> I note that the relevant draft in sunset4 has been updated in 3 years, and Sunset four hasn’t meet since IETF97.  Doesn’t seem like anything will happen there.

The SUNSET4 working group still has an active charter.

> We wrote this to solve what I think is a real issue observed with the use of NAT64 on the IETF100 network.

It’s not a good solution. The issue is quite a bit more complex than jamming a new flag into the RA message will allow.

Consider the current behavior of some of the products that my employers produce, which send RA messages (lifetime=0) on their Wi-Fi interfaces to distribute PIO elements to hosts that need ULA addresses in the Nest Weave fabric space. Under this draft, each currently fielded Nest device would cancel the 4=1 flag sent by any IPv6-only default gateway. Which is a kinda silly thing to do when you’re a router between Wi-Fi™ and Thread™ and Thread™ is an IPv6-only link layer. Wouldn’t you think setting 4=1 to be a good idea in that case? Alas, it’s not. If we do that, then any dual-stack hosts on a network with an IPv4-only CE router will shut off their IPv4 activity, and they will not get any IPv6 service through us. This is probably not what anyone wants, so we would of course never ever, not in a million years, never send 4=1 in our RA messages.

Now, you might say we shouldn’t send RA messages at all (even with lifetime=0) unless we are willing to be a default router. You might say that the default router should forward our Weave fabric prefix to us from hosts on the LAN. And I would say, that sounds like a capital idea, except each and every one of the workable technical alternatives to get hosts to self-assign on-link addresses, and set host route entries for a working route to the rest of the Weave fabric behind our local router, or at least to have a reliable means of routing on home networks through the usual default route at the CE router, have all been roundly rejected by industry and at least three separate IETF working groups. We do what we can because it’s the only thing that works.

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.

--james woodyatt < <>>