IETF Logo Mail Archive

Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

sthaug@nethelp.no Wed, 22 April 2015 07:31 UTC

Return-Path: <sthaug@nethelp.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74251B32C2 for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 00:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qLwGKRrltfkt for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 00:31:11 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 923B61B32DE for <v6ops@ietf.org>; Wed, 22 Apr 2015 00:31:03 -0700 (PDT)
Received: (qmail 84640 invoked from network); 22 Apr 2015 07:31:02 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 07:31:02 -0000
Date: Wed, 22 Apr 2015 09:31:02 +0200
Message-Id: <20150422.093102.41714241.sthaug@nethelp.no>
To: jeroen@massar.ch
From: sthaug@nethelp.no
In-Reply-To: <55374C42.7030908@massar.ch>
References: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com> <20150422.091227.74668510.sthaug@nethelp.no> <55374C42.7030908@massar.ch>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/wbwGLvYicknB26H4GJfRoLRwOj8>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 22 Apr 2015 07:31:13 -0000

> > I see no reason to deprecate IPv6 EHs. But I need 
> > 
> >  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit
> > 
> > in order for the router hardware to be able to filter based on TCP/UDP
> > headers at line rate.
> 
> The nasty answer to such a statement is: increase your hardware
> inspection limit.

And that will probably happen - as part of regular equipment upgrade
cycles.

> But the easier one, that works today is that very likely your DNS
> servers recursing IP space is dedicated.
> 
> Hence, any packet headed toward those addresses is "private" and should
> not get an answer.
> 
> Thus, instead of doing filtering on L4, why not just not route those
> packets at all (L3)? Don't even have to firewall it.

The world is not that simple.

> Btw, does your hardware-load-balancer inspect ICMPv6 to do stateless
> flow routing for ICMPv6 errors to the correct host? Or are you also just
> fumbling with ICMPv6 PTBs like Amazon (+NetFlix) & Google?

Don't have those boxes doing IPv6 in my network.

Steinar Haug, AS 2116

v2.23.0 | Report a Bug | By Email