I'm curious on how the non-contiguous ipv6 [1] usage will eventually affect the use of the TCAM in vendor hardware. It seems that most TCAM being developed today will never be able to store anywhere near the unfathomably large amount of possible address prefixes being carved - and of course the prefixes are only are going to get more and more fragmented.
Right now the typically default behavior for switches/routers that encounter the exhaustion is to summarize prefixes with a shortened prefix and (possibly) punt the evaluation to the general purpose CPU (example here[1]) - which suffice it to say, introduces a host of security concerns. This means, as a security engineer, in situations where complex/large ACLs exist, I need to be aware of and control how IPv6 TCAM exhaustion failure modes work and plan that eventually my hardware TCAM may be exhausted and fail in a spectacularly bad way.
Or, I just ignore IPv6 almost entirely and just don't have the problem (cleverheadtap.jpg)
Right now the typically default behavior for switches/routers that encounter the exhaustion is to summarize prefixes with a shortened prefix and (possibly) punt the evaluation to the general purpose CPU (example here[1]) - which suffice it to say, introduces a host of security concerns. This means, as a security engineer, in situations where complex/large ACLs exist, I need to be aware of and control how IPv6 TCAM exhaustion failure modes work and plan that eventually my hardware TCAM may be exhausted and fail in a spectacularly bad way.
Or, I just ignore IPv6 almost entirely and just don't have the problem (cleverheadtap.jpg)
[1] https://www.iana.org/assignments/ipv6-unicast-address-assign... [2] https://community.cisco.com/t5/switching/tcam-utilization-is...