Re: A problem with RFC 6465's Uniform Format for Extension Headers

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 09 February 2014 22:44 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CCC1A0618 for <ipv6@ietfa.amsl.com>; Sun, 9 Feb 2014 14:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 gCYgKPYkZDvE for <ipv6@ietfa.amsl.com>; Sun, 9 Feb 2014 14:44:06 -0800 (PST)
Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B2F031A0506 for <6man@ietf.org>; Sun, 9 Feb 2014 14:44:06 -0800 (PST)
Received: by mail-pb0-f45.google.com with SMTP id un15so5467339pbc.32 for <6man@ietf.org>; Sun, 09 Feb 2014 14:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ky+IAmSUt+gZgtOznRcH5eYQiAanSIo+nkQeoWxM12E=; b=f62A/G7qFwqEJzZRlA7Icm1SLnhsSTYy6VLLKOf7uX3JEHaV0Z/z9S5I6I23P8cn50 3HTMno5dZf+QCDLd2lCduyJSKoR08rB4UB+Mp+zYWT2HNdpFuUGvvc3MJsr9h90CdSvN jPNpj1ZRPraxzx3z2MEyP+ombrXUZMU5YtUytdHkIPDGtzCt9W6zsHNnoi4Y4MobusF5 YM4qud/PPnTsK9GlNkIqe/kPu4fgdXZmhMg+YUZ3QnBigNxCCbUZb7lwpUnZlydXshrc 9NWmCmjwNhWnUJqSPWyrW/QhHT3TL23ljei922dhMNXqLwtXh5OYdPvtrRNBdNQGdg5i IZfg==
X-Received: by 10.68.176.65 with SMTP id cg1mr5476585pbc.145.1391985846949; Sun, 09 Feb 2014 14:44:06 -0800 (PST)
Received: from [192.168.178.23] (82.197.69.111.dynamic.snap.net.nz. [111.69.197.82]) by mx.google.com with ESMTPSA id q7sm35749629pbc.20.2014.02.09.14.44.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 14:44:06 -0800 (PST)
Message-ID: <52F804B3.5040803@gmail.com>
Date: Mon, 10 Feb 2014 11:44:03 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <CAFU7BATrYRsNJ7D4AJSy62XobNaGDgW-zTvX=yrqZea-Q67YPA@mail.gmail.com> <52F13D1D.9050800@gont.com.ar> <Pine.LNX.4.64.1402090915000.27591@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1402090915000.27591@shell4.bayarea.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Fernando Gont <fgont@si6networks.com>, 6MAN <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 09 Feb 2014 22:44:09 -0000

On 10/02/2014 08:35, C. M. Heard wrote:
...
> In the absence of a strong argument to the contrary, it seems to me 
> that the existing Destination Options header can be used to do 
> exactly the same thing as the proposed UEH.  In other words, I agree 
> with Jen's comments.

I think we should carry out a thought experiment: consider each
of the existing extension headers, listed in RFC 7045 and at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
and see which of them could or could not be encoded as
destination options.

For some of them the answer is obvious, of course. But the others would
give us an idea whether the 'option' option has enough flexibility.

    Brian