IETF Logo Mail Archive

Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 19 November 2017 22:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 656151200CF for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 14:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 dpwt-FJa4rD5 for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 14:47:20 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989BD12009C for <ipv6@ietf.org>; Sun, 19 Nov 2017 14:47:20 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C395820072 for <ipv6@ietf.org>; Sun, 19 Nov 2017 17:49:15 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 08CBB829D1 for <ipv6@ietf.org>; Sun, 19 Nov 2017 17:47:19 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipv6@ietf.org
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com> <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 19 Nov 2017 17:47:19 -0500
Message-ID: <13934.1511131639@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tRZ1D2JqX58J-iHwLqEKSgGYXP8>
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: Sun, 19 Nov 2017 22:47:22 -0000

Christian Huitema <huitema@huitema.net> wrote:
    >> (As to whether this belongs in 6man or sunset4, that's a secondary question.
    >> As for the other comments on this thread, I am too jet lagged to respond
    >> right now... later.)

    > How about a transition rule for dual stack implementations? If there is
    > IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify
    > that rule with availability of a 6to4 prefix?

    > Yes, looks for something sunset4 should work on, if sunset4 is actually alive.

I think that Erik's description got things: it's about saving joules of power
by not trying too hard to find IPv4 when it's just not around.

I think that you (Christian) bring up the question for a future where IPv4
networks are rare and IPv6 is universally deployed.   Should we make some
provision today for that eventuality so that products in the field will do
the right thing at the right time?   What exactly do we mean by that?
(Not every device is a smartphone that gets replaced every two years and
firmware upgraded a few times a year)

Jen makes the good point that if we are concerned about the infrastructure
being bothered by 0x800 packets (and perhaps more annoying arp broadcasts),
then we should just block the packets in the right places.  I think that this
is sometimes good advice.  But, I'm a bit concerned when we advise blocking
things like that... how many of us have tried to run IPv6 LL traffic over an
infrastructure that decided anything !0x800 must be was evil?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email