Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

Ray Hunter <v6ops@globis.net> Fri, 05 July 2013 13:11 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D211E82C3 for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 06:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImlTs5WcMmPO for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 06:11:57 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 98C8211E82DB for <v6ops@ietf.org>; Fri, 5 Jul 2013 06:11:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B928C87007F; Fri, 5 Jul 2013 15:11:36 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT8zS8nBrnoo; Fri, 5 Jul 2013 15:11:36 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1D351870002; Fri, 5 Jul 2013 15:11:36 +0200 (CEST)
Message-ID: <51D6C601.70003@globis.net>
Date: Fri, 05 Jul 2013 15:11:29 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Gert Doering <gert@space.net>
References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <CAD6AjGSGeNHPUs9+F6OOAeDOy_FZpTOGkH6viX_fENca4H8X0g@mail.gmail.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net>
In-Reply-To: <20130705124651.GP2706@Space.Net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 13:11:57 -0000

Gert Doering wrote:
> Hi,
>
> On Thu, Jul 04, 2013 at 05:36:06PM -0700, Joe Touch wrote:
>> So let's please be very clear about what _this_ draft is saying - it is 
>> NOT about making routers do something that routers *need* to do.
>
> If you can build a router for me that has a control plane which is 
> completely unreachable from the outside, that would be sufficient
> (but that would likely be a MPLS P router, who wouldn't need to look
> at *any* IPv6 bits).

Right.

> Today's routers *need* to be able to protect themselves, and that can
> only be done by L4-aware rate limiting and ACLs.

So could we specify different requirements and solutions for control
traffic which terminates on the router, compared to end user traffic
which only transits it?

If so, couldn't this requirement be implemented as "being able to filter
at wire speed any traffic headed for the control processor based on a
IPV6 source prefix", rather than having to filter on a full L4 header?

And then numbering end user LAN's from prefixes completely disjoint from
your control network ranges and BGP peer addresses?

If it's more than this I think it'd help to better specify the requirement.

> So please stop repeating this "a router doesn't need any of this" - while
> this is fairly nice for a theoretical router, it doesn't work out there,
> and *this* is what should be interesting.  Not "ivory tower beauty".
>
> Gert Doering
>         -- Operator