IETF Logo Mail Archive

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

Dan Lüdtke <maildanrl@gmail.com> Fri, 14 February 2014 16:58 UTC

Return-Path: <maildanrl@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 188931A031D for <ipv6@ietfa.amsl.com>; Fri, 14 Feb 2014 08:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 1wtwpvZreiST for <ipv6@ietfa.amsl.com>; Fri, 14 Feb 2014 08:57:59 -0800 (PST)
Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A66891A0319 for <6man@ietf.org>; Fri, 14 Feb 2014 08:57:58 -0800 (PST)
Received: by mail-pb0-f42.google.com with SMTP id jt11so12603587pbb.29 for <6man@ietf.org>; Fri, 14 Feb 2014 08:57:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wwyr5N+Ei1uFOTF3IukYLvlA6+o0K0y8UaN2LjF4+yo=; b=vW+1lfUTRxGvByl9R1ANlOeO5dtrGNcsh8F4yt/I6/AwOLFzJyNFBJU+1Dc9noBHZg fbOsDiOjnLiVdocv3Bdwoj7enffKQi15N3vOx0wR8t3IHbnrKuhx15oX8B9fEKPZKSvP SCjtro+HFPMQZJtRfhXALn4D9TyppWjEImjPTZYcmsC405Yl5KYGz9oDKCXZRFuV4zfU v+pbCqrL+BPXGrIontPw92D4uYRL1veYbi8QDl3ZAT5Vaj/CQERy66LGqlrk9XawVBKz 5KSsXOpFAyoudkCGyrMUP1PuSK0ieW/9GwcNKEFALNA6gMZjBKyKpqCC1zaJ2U0xvgrP sMaw==
X-Received: by 10.68.201.97 with SMTP id jz1mr10426633pbc.26.1392397077051; Fri, 14 Feb 2014 08:57:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.104.66 with HTTP; Fri, 14 Feb 2014 08:57:36 -0800 (PST)
In-Reply-To: <52FDDA1B.3060104@si6networks.com>
References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <m3k3d82zz6.wl%narten@us.ibm.com> <52F383A0.7030002@si6networks.com> <m28utnbwj9.wl%randy@psg.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> <52F927E0.5080706@gont.com.ar> <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> <52FDDA1B.3060104@si6networks.com>
From: Dan Lüdtke <maildanrl@gmail.com>
Date: Fri, 14 Feb 2014 17:57:36 +0100
Message-ID: <CAAfuxnLCZXu6JepOqMWfHAzCSJaDao=oLnuyPYKrNK9327xgjg@mail.gmail.com>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xck_8n2dlj5w_3rr3gLFAB5vTTI
X-Mailman-Approved-At: Fri, 14 Feb 2014 13:10:42 -0800
Cc: Thomas Narten <narten@us.ibm.com>, "6man@ietf.org" <6man@ietf.org>, "C. M. Heard" <heard@pobox.com>, Tim Chown <tjc@ecs.soton.ac.uk>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Fernando Gont <fernando@gont.com.ar>
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: Fri, 14 Feb 2014 16:58:01 -0000

We all do not know what the future might bring, so being able to
differentiate between an unknown IPv6 extension header and an unknown
upper layer header should not be considered unimportant. I prefer
reserving a range over creating a new registry. The main reason is
that I am developing IPv6 software and it is easier to keep the
parsing tree short.

E.g. exthdr->option vs. exthdr->subexthdr->option


Some nitpicking:
In section "3. Problem Statement": typo: "on the fat" -> "on the fa_c_t"
In section "5. Operation of the UEH": typo: "discusses de operation"
-> "discusses _the_ operation"

That's all for now, have a nice weekend everyone.

-- 
Dan Luedtke
http://www.danrl.de

v2.23.0 | Report a Bug | By Email