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

Gert Doering <gert@space.net> Wed, 22 April 2015 08:51 UTC

Return-Path: <gert@Space.Net>
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 5B2871B317F for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 01:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lpf_WWHF16TJ for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 01:51:42 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E640B1B2F65 for <v6ops@ietf.org>; Wed, 22 Apr 2015 01:51:41 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A18AA608A5 for <v6ops@ietf.org>; Wed, 22 Apr 2015 10:51:39 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2DD2E60A3F for <v6ops@ietf.org>; Wed, 22 Apr 2015 10:51:39 +0200 (CEST)
Received: (qmail 64891 invoked by uid 1007); 22 Apr 2015 10:51:38 +0200
Date: Wed, 22 Apr 2015 10:51:38 +0200
From: Gert Doering <gert@space.net>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Message-ID: <20150422085138.GE54385@Space.Net>
References: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/eTfWrhPvI4AHg7taHjwpGqUQ-7g>
Cc: "v6ops@ietf.org" <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 08:51:44 -0000

Hi,

On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.
> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same
> place in the packet, so that hardware can look at them for the
> purposes of dropping them in hardware or as inputs into LB. Is that
> the case?

No :-) - Hardware *is* sophisticated today, but only up to a certain limit.

What I think would be implementable with reasonable tradeoffs between
"unsane hardware effort that my end customers are not going to pay" and
"still flexible" is to require that the final EH is contained in the 
first <n> bytes (say, 512) and that the final header must be in the 
first fragment.

Right now, we have "the packet can have any size, and the final header can
be anywhere" - and doing that in hardware is just too expensive.

> What I'm curious about then is how do you handle DDoSes that are
> using IP fragments, where there are no TCP or UDP headers ports to
> look at?

That is actually quite easy: rate-limit fragments against the control plane, 
and drop first fragments if there is no L4 header inside.

(The thing is: not all packets are equal - for some, like ICMP, you want
to permit them towards the control plane up to a certain limit - say, 
10 Mbit/s, sufficient to permit people to do network testing, but not 
to overwhelm your control plane link or CPU.  For others, like BGP from
established peers, you take what they give you, because it speeds up 
convergence.  BGP SYNs, rate-limit.  And so on)

> I'm also curious about how you LB packets (either at layer 2 or
> layer 3) that don't have TCP or UDP headers, or aren't IP. I've
> seen LB become completely ineffective at layer 2 because a customer
> was using MPLS between two routers, so no MAC address variation,
> and no IP addresses and no TCP or UDP ports to look at.

This is actually a hard problem in the generic case.  If the hardware can
find reasonable discriminators, you can hash based on that (like, MAC 
addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
or "src/dst MAC address", which is usually a spectacularily bad idea 
between routers.

[..]
> "LAG is good, but it???s not as good as a fatter pipe."

True.  But sometimes life is not nice, and you have to live with what
you have - like, you can get 2x 10G wavelength between cities, but not
40G or 100G, or your equipment just cannot handle 40G/100G.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279