IETF Logo Mail Archive

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

Hagen Paul Pfeifer <hagen@jauu.net> Fri, 07 February 2014 22:19 UTC

Return-Path: <hagen@jauu.net>
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 0ED711A0449 for <ipv6@ietfa.amsl.com>; Fri, 7 Feb 2014 14:19:12 -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_HELO_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 BYZDk3CDolrE for <ipv6@ietfa.amsl.com>; Fri, 7 Feb 2014 14:19:09 -0800 (PST)
Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF671A021E for <6man@ietf.org>; Fri, 7 Feb 2014 14:19:09 -0800 (PST)
Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from <hagen@jauu.net>) id 1WBtjw-0008OO-Dk; Fri, 07 Feb 2014 23:17:40 +0100
Date: Fri, 07 Feb 2014 23:23:39 +0100
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
Message-ID: <20140207222339.GA28019@localhost.localdomain>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m3k3d82zz6.wl%narten@us.ibm.com>
X-Key-Id: 98350C22
X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "C. M. Heard" <heard@pobox.com>, Fernando Gont <fgont@si6networks.com>, Tim Chown <tjc@ecs.soton.ac.uk>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
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, 07 Feb 2014 22:19:12 -0000

* Thomas Narten | 2014-02-06 07:21:49 [-0500]:

>But we are already there. Folk won't deploy anything other than
>TCP/UDP because NAT won't deal with it. That has already been reality
>and is the reason that other or new transport protocols appear to be
>virtually undeployable today.

Maybe actual in parts of the Internet. We deploy larger networks with our
router silicon and we _use_ IPv6 extension header to transport signaling
information. Period. Our need is not on the protocol side - UDP is fine for
all - we need additional extension header (think about roaming information).
And we _have_ actual problems with the current situation! This is why I wrote
the I-D back in 2011[1].

I remember a time where ECN did not work properly and where dropped
occasionally by broken middleboxes. LKML started to enabled ECN and things
improved over time.

We should not stop solutions here because administrators/vendors infringe
protocol best practices. We should focus on an proper protocol design which
enables possibilities.

Hagen


[1] http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01

v2.23.0 | Report a Bug | By Email