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

sthaug@nethelp.no Wed, 22 April 2015 11:25 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 421C71B34A2 for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 04:25: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 i8CgFvPt5yRj for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 04:25:11 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 909401B349C for <v6ops@ietf.org>; Wed, 22 Apr 2015 04:25:10 -0700 (PDT)
Received: (qmail 93540 invoked from network); 22 Apr 2015 11:25:08 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 11:25:08 -0000
Date: Wed, 22 Apr 2015 13:25:08 +0200
Message-Id: <20150422.132508.112543177.sthaug@nethelp.no>
To: markzzzsmith@yahoo.com.au
From: sthaug@nethelp.no
In-Reply-To: <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
References: <20150422085138.GE54385@Space.Net> <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
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/qaldQgGJU6pLP9R3g19aih0lts8>
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 11:25:13 -0000

> So would you expect all of your routers to be able to do this
> level of processing?

Yes.

> It seems to me that you'd only need routers that can do that
> processing facing potential malicious sources e.g. transit, peering,
> and possibly customer (although customers have a strong disincentive
> because it is in their interests for the router to stay
> available).

Customers themselves may have such a disincentive (unless they are
trying to deliberately sabotage the network infrastructure - which has
been known to happen). Customer PCs and other equipment which are
"owned" (i.e. part of a botnet, under control of an external party)
may well have a strong incentive to deliberately create problems.

> I wouldn't think it would be worth the expense to have
> this level of hardware filtering available on core routers.

Reasonable arguments can be made either way (Same level of hardware
filtering for core routers: Potentially more expensive hardware, but
potentially simpler logistics - fewer hardware product variants).

I *might* consider core routers without such hardware filtering *if*
I was running a pure MPLS core, and was reasonably certain customer
traffic wouldn't hit the core routers directly.

Steinar Haug, AS 2116