IETF Logo Mail Archive

Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Fri, 31 May 2019 09:37 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 8770B1200A3 for <ipv6@ietfa.amsl.com>; Fri, 31 May 2019 02:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 68yfYwoXU1-1 for <ipv6@ietfa.amsl.com>; Fri, 31 May 2019 02:37:51 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EAA12004C for <ipv6@ietf.org>; Fri, 31 May 2019 02:37:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hWdys-0000HJC; Fri, 31 May 2019 11:37:46 +0200
Message-Id: <m1hWdys-0000HJC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <561d9dc3-c769-c774-8f65-f975ac2a10a0@gont.com.ar> <m1hT1DZ-0000HEC@stereo.hq.phicoh.net> <ce07ade8-5105-055f-4798-f4ef20a2393c@si6networks.com> <CAN-Dau02MYCrKx2BgyuYJeHBdoz6SHCnp+-byM+LMM8af0S+rA@mail.gmail.com> <40e99171-6dda-29e3-6152-da5ca5219ed9@foobar.org> <CAN-Dau0ALqfAA-Dz56oHAfOtY7E2obx5E7TgoeH357Mckp3t9g@mail.gmail.com> <093ba8e2-6f0a-4c91-9df1-cda33fffea97@foobar.org> <CAN-Dau3kVqb+ZEHB7iPGeRuq1Mu8UHR3FEZv8SgmiqZexaFhuA@mail.gmail.com> <12db9629-f92a-e12a-5ff1-7db2c5d2137e@foobar.org> <F6F0C9DC-545E-4FE5-BB4C-55BB29022E84@steffann.nl> <CAO42Z2yUDi3FHOZsLrHqwLsEWkB1X9FREa8m6dU6ecOr=SsX4g@mail.gmail.com> <E51102E7-D4F0-4469-8888-5072F624EE06@steffann.nl> <CAN-Dau1S57wQ+3+m+m5grMe5N2SdfFqhELteSYfkmAC85_8H3w@mail.gmail.com> <8523a960-d551-1c24-d756-10c1840289de@foobar .org> <CAN-Dau27O9QB9MHhk81RsewwpH=xW=D1ZrUDmEq+WP0_Fyeh5Q@mail.gmail.com> <m1hVeWz-0000HvC@stereo.hq.phicoh.net> <789fe5a4-aa48-1ce4-8226-d7f73c2 c24d7@gmail.com>
In-reply-to: Your message of "Wed, 29 May 2019 09:54:27 +1200 ." <789fe5a4-aa48-1ce4-8226-d7f73c2c24d7@gmail.com>
Date: Fri, 31 May 2019 11:37:45 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ab5vKUPxzx98W6Vj9RAL_6Yi2f4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 31 May 2019 09:37:54 -0000

>Wait, on that argument the host shouldn't waste resources on IPv6 either. 

That might be the best reason we don't have to care about hosts.

If hosts can deal with IPv4-only without running into battery issues, then
hosts can deal with IPv6-only networks as well.

>The
>theory here is that the desired endpoint is IPv6-only in switches, routers
>and hosts, in a world where dual stack hosts have to be ready for dual stack
>operation for obvious reasons.

If we were talking about IPv6-only hosts, then there would be no need to
discuss what to do with IPv4.

So we can assume that hosts are dual stack (or IPv4-only). The easiest
solution for network operators is to just configure switches to drop 0x800
and 0x806. Problem solved. No need to update routers, no need to worry
about IPv4-related security issues.

v2.23.0 | Report a Bug | By Email