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

[Nick Hilliard <[e-mail]>]

Mark,

Gert and Steiner have answered many of the issues which you bring up.

On 22/04/2015 07:20, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

The emperor is not naked.  We live in a real world with real constraints.

> 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?

Nope, EHs cannot be removed from the spec and no-one is suggesting this.
As Steiner said, we need something like:

>  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit

I'd suggest that we need a chunk of encapsulation overhead in that
equation.  The hardware inspection limit will vary, but the larger it is,
the more expensive both in terms of financial cost and performance.

> 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?

s/rtbh or d/rtbh, depending on which looks like it will be more effective.
 But please don't try to imply that because something is broken in ipv4
that we should be ok if it's broken in ipv6 too.  This is a unhelpful fallacy.

> 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.

tbh, with great difficulty and expense.  I spend an inordinate amount of
time trying to deal with this particular problem.  And if it's bad for the
L3 ISP stuff I do, it's far worse on an L2 IXP lan.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered by
> the bridge as normal bridge ports, so if you want to avoid loops across the
> links that are candidate members of the LAG, the IEEE expect you to be
> running STP of some form across them...)

yep, bridges require bridging protocols for loop avoidance.

>, I'm a big fan of the quote on the
> last slide of this presentation:
> 
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
> 
> "LAG is good, but it’s not as good as a fatter pipe."

which is fine until the point that a fatter pipe will not handle all the
data you need to transfer.  If I had a choice about using LAGs, I wouldn't
use them.  I don't have that choice.

Nick