Re: Usable extension headers

Havard Eidnes <he@uninett.no> Thu, 28 November 2019 19:47 UTC

Return-Path: <he@uninett.no>
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 0A3991208C7 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 11:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uninett.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 CGit8LlSZtFE for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 11:47:44 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6381208C8 for <6man@ietf.org>; Thu, 28 Nov 2019 11:47:43 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9A3A443EA8C; Thu, 28 Nov 2019 20:47:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1574970459; bh=OcM/umvZ3fOd7UzHHpG/fN3/wqMtajzmNMLlW0zxrag=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=RQvat8kgf5zsg59lqxUOuVTxARLhS/DbVTJsuVOdtLHM5LjHKYoo7/fwXrH4wwbH7 z7GG/NYTf6j+KXlHlVjC6uFLzkkGelEEJn7yAIoWqSik1AhvVVpROLQKZpVm3pQlpc eD6E9qYMfsIcSsU+OOKVjwqR/3nY86EwLEJ+jeUc=
Date: Thu, 28 Nov 2019 20:47:39 +0100
Message-Id: <20191128.204739.985193470719683956.he@uninett.no>
To: tom@herbertland.com
Cc: brian.e.carpenter@gmail.com, 6man@ietf.org
Subject: Re: Usable extension headers
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <CALx6S35VCijYqKrQyLwkbToGgYppwqeH06MXzojepV-YCuO=qQ@mail.gmail.com>
References: <d791c9eee34c4e019292fc74d629217c@boeing.com> <5d2af468-be61-d2ca-5bf0-35d5f71fdb6c@gmail.com> <CALx6S35VCijYqKrQyLwkbToGgYppwqeH06MXzojepV-YCuO=qQ@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 26.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/epqs3UWmm3US7AXVLX00Lv5o-gA>
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: Thu, 28 Nov 2019 19:47:46 -0000

> So the problem is how do we deploy protocols that aren't necessarily
> supported across all possible paths. I think the answer is already
> known: if we have a priori knowledge that some path supports a
> protocol then use the protocol, if the particular path doesn't support
> a protocol then don't use it and fall back to a degenerative protocol
> more likely to be palatable. There are several examples of this
> technique: Happy Eyeballs for IPv6, QUIC fallback to TCP, UDP DNS
> fallback to TCP DNS, etc.

Those are all mechanisms deployed by hosts, where the probing of
failure or success can be done with some reliability.  If I've
understood correctly, what we're talking about instead is routers
along the path messing with the IPv6 packet in non-standard ways,
and the router which did the messing doesn't under normal
circumstances get the same signal hosts do when a host connection
carried over this path either fails or succeeds.

Regards,

- Håvard