IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Sat, 18 November 2017 16:03 UTC

Return-Path: <fgont@si6networks.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 0B37A126C2F for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 08:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.075
X-Spam-Level: *
X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DATE_IN_PAST_03_06=1.076, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 E8xBR1S9_W8R for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 08:03:28 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2677120726 for <ipv6@ietf.org>; Sat, 18 Nov 2017 08:03:28 -0800 (PST)
Received: from [172.19.248.238] (unknown [57.190.1.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3CB4F80A81; Sat, 18 Nov 2017 17:03:17 +0100 (CET)
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Lorenzo Colitti <lorenzo@google.com>, james woodyatt <jhw@google.com>
Cc: IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Fernando Gont <fernando@gont.com.ar>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com> <CAKD1Yr3vqJB9_virMp7+uH2zOYLDM+XNf=L1OihN0DdXzCNobA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <c839442e-0d2b-4f8e-5348-7cdd655ccad8@si6networks.com>
Date: Sat, 18 Nov 2017 20:14:41 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr3vqJB9_virMp7+uH2zOYLDM+XNf=L1OihN0DdXzCNobA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ErJqvhy7mTu17hwy30Go6Y6_hQ8>
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: Sat, 18 Nov 2017 16:03:30 -0000

On 11/18/2017 04:46 PM, Lorenzo Colitti wrote:
> On Sat, Nov 18, 2017 at 11:20 AM, james woodyatt <jhw@google.com
> <mailto:jhw@google.com>> wrote:
> 
>     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.
> 
> 
> Yep, a single flag won't work unless all routers agree on it. What about
> an option that signified there was no IPv4 on the network? If the option
> is sent by any of the routers on the link, then hosts would not attempt
> IPv4 configuration.

What would be the difference between encoding the info in an option vs
in a flag?



> Not sure how that would support IPv4 becoming available once the option
> has been set. Also, not clear how to deal with the DOS scenario where a
> rogue RA disables all IPv4 on the network until the end of time.

The only "fix" would be accepting that both versions of IP have become
more and more entangled, and as soon as there's an attack vector  in one
of them, the other version of the protocol can be screwed up. --
something along the lines of RFC7123 and  RFC7359.

Me, I'm generally of the idea of keeping both protocols as
separate/isolated as possible. But if the wg decides to pursue the idea
in this document, the above model of "now one version of the protocol
can be attacked via the other version" should be clearly stated.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email