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

Bob Hinden <> Sat, 18 November 2017 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49A8124E15 for <>; Fri, 17 Nov 2017 18:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 nW4BsPbIU3zW for <>; Fri, 17 Nov 2017 18:39:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F27D120721 for <>; Fri, 17 Nov 2017 18:39:42 -0800 (PST)
Received: by with SMTP id b189so9691799wmd.0 for <>; Fri, 17 Nov 2017 18:39:41 -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=fXIUfZFSLm2+2NeUmJfF5soWJqsTXvwh3UeCW69gXek=; b=qCjkr0il78kHl7I1BKSlmMpbk6kJnDurCR5ucb4ol1XXX/vr4r+vDGosVfNaZOo3ez 3JXdEf6Q/W4IFJzMe4Y2Q8dTVSrSoMA+q8U3kqMRSyqs3+iIaBvMP8pP4c5i4uxDZYzp b7684i9ECGTicLUtBMlzB9dM0hicvaJMBW6nfmY6/ni3XIpn3WWsL4EQBAl5HdjhNe7x JgmVpcBMSiF4Mbnp49HIbGIsrpxHSlOwGIICVlKv2kjtuQ/Dhuxl50vwvNgCe0DrA7ct rIjj8G/BkBUqcuGi1FFTomrw9qSoBujt8sNAH6PflVIkz+ERTofLZT/zlbDqn+BM9a81 kceQ==
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=fXIUfZFSLm2+2NeUmJfF5soWJqsTXvwh3UeCW69gXek=; b=njYuug+zc9F+JUBplc75zlq5IPSOXX3DmGmSjbXfz29+AHtcUv7d24Wwe9+D1rsaKE H1vboYcTiznmaM5QiDQ4GRaiCMGTkHYDJcN8ZHqZhhWN9rn/dooLfZd6RvzqUF5YjUvZ V6ZJ+uxniL26sP1idWiSOEF7Q9T7MW4eg/FsUW4cUzxITsBs2lkBHEF/7Mue4Zdvyhn1 9SiLUg4uvt84SIVNUxZLm+kScpQKkJobOT5VkaNrFytZOhX9NaY7xqhBRXADM6vdhLn4 Oj9DNsVZIJrNbOcDQXKJzIhG1TRfpBmdljMDNcpAmN8nL5Bd2Pt/Kjk3Jqmf1opvQd7B L0OA==
X-Gm-Message-State: AJaThX4khCH3PKWbEOrBvk2iKz8XfjD4BZbOoTxnUKEda9ryefVYvaEQ R7/9A1pCnCirOvz4NX+AwiM=
X-Google-Smtp-Source: AGs4zMaLZRkLHo+bbHlfeX2cROU6vBO09Olnubnp8WHUiVW1eNREVy3lHvC3n6ML4IczTw/tk/C0+A==
X-Received: by with SMTP id j4mr4585521wmj.55.1510972780568; Fri, 17 Nov 2017 18:39:40 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:59aa:f59:2eed:52fb? ([2001:67c:1232:144:59aa:f59:2eed:52fb]) by with ESMTPSA id t19sm2887245wrb.58.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 18:39:39 -0800 (PST)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_DD946799-A194-4766-8114-9735D24E3C66"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Sat, 18 Nov 2017 10:39:34 +0800
In-Reply-To: <>
Cc: Bob Hinden <>, IPv6 List <>
To: james woodyatt <>
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:39:45 -0000


> On Nov 18, 2017, at 10:20 AM, james woodyatt <> wrote:
> 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.

I hadn’t thought of this use case (using IPv6 on a link with only IPv4 internet connectivity), I agree that you would not want to be setting the flag to 1 unless you had knowledge of there not being any IPv4.

Would the issue be resolved if the text said something to the effect of only act on this flag if the router is also saying it is a default router, that is lifetime > zero?  I think that is the intent.   Seem to me this would allow you to continue your current operation and not disrupt the IPv4 on the link.

Also, who am I to argue that you shouldn’t use ULA addresses :-)


> 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 <>