> On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) <[email protected]> wrote: > > Fernando would like to see a specification of how long the entire list of > > extension headers may be, in terms of "how large of a hardware buffer has > > to be implemented in a switch?" That has a couple of issues related to "why > > does one have to ask the question?" The hardware should definitely be large > > enough to read in the IPv6 header, the HBH Header, and the Routing Header. > > After that, the only host that SHOULD need to read it all in is the host > > itself, and the host can do its processing from RAM. There is one "gotcha" > > case, which is when someone uses an ACL (disallowing Fragmentation Headers, > > perhaps, or looking for the TCP port, meaning one has to ask whether a > > given packet is TCP and what its port number is). The firewall is going to > > have to chase down the chain of extension headers.
You may call it a firewall. I call it a "border router" - and the difference between this and a firewall is striking. Most importantly, my border routers don't keep state for the sessions passing through them. However, I *do* expect them to handle basic stateless ACLs, including L4 info (port numbers). For IPv4 and IPv6. > I agree. There is a definitely a big difference in requirements for > "traditional routers" and devices which are going to implement ACLs > (and other types of "multifields classifications" (as QoS based other > data than IP header). IMHO it's reasonable to assume that one might > need different hardware for "just routing" and enhanced QoS/ACL > services (it's a case nowadays anyway). You may feel it is reasonable. Not everybody agrees. If we compare with IPv4: All modern routers I know of (including high speed boxes with multiple 10G and 100G ports) are able to handle stateless ACLs based on IPv4 addresses and port numbers. The boxes with multiple 10G and 100G ports process these ACLs at line rate. I don't pay extra for this functionality - possibly because a box *without* such functionality would have a limited market. > For the latter case the device > has to either, as you said, chaise the whole chain down (which might > be as long as the whole packet) or have a way to deal with packets it > could not parse (applying a specific policy to such packets). > > > How big is a HBH header? How big is a routing option such as the Segment > > Routing option? If that's a list of 27 services, each with a 16 byte IPv6 > > address... A small but possibly relevant digression here: My border routers (which happen to be Juniper routers) are configured to disallow source routing. This has been the Juniper *default* since around 2008, see http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-routing/frameset.html I expect (but do not know with certainty) that Juniper changed this source routing default behavior based on customer feedback. Back to IPv6: I might allow "interesting" IPv6 extension headers within my own AS - because in such cases I have much more control. There is no way I'm going to allow IPv6 packets with long chains of "interesting" IPv6 header chains to pass my border routers. Either they have short enough header chains that my border routers can inspect the L4 info at line rate - or they get dropped. > I'd like to point out that the problem is not specific to IPv6 at all. > How deep is MPLS label stack? Where are TCP flags or port number in > the packet (so I can match 'tcp established' or 'tcp 443')? oops, we > don't know....it depends...so some linecards do not copy enough data, > some (newer ones) do. The MPLS label stack is normally used with a single provider - thus the provider is in control. I agree that the IPv4 packet may have options, making it variable length. However the length is still limited by the IHL field, which has a max value of 15 (60 bytes). Steinar Haug, AS 2116
