Practical IPv6 Filtering Ben Eater eater@juniper.net

IPv4/IPv6 Feature Parity Features and tools will lag Vendors need to figure out what will be useful before committing engineering resources Not everything published in an RFC will get implemented Early adopters like DREN are instrumental in guiding this process Once basic IPv6 forwarding is implemented, most other features can be easily added Filtering (and features that rely on it) presents additional challenges

Filtering IPv6 Filtering is required to implement many security mechanisms Simple accept/discard actions Selecting traffic to monitor/log/count/mirror Rate limiting Policy route, QoS handling, others… Filtering IPv6 traffic presents some challenges.

Filtering IPv6 in Software Pros Very easy to do Cons Lack of predictable performance Impossible to use in high-bandwidth applications Lack of headroom can allow attacks to exhaust limited CPU resources even in lower bandwidth applications

Filtering IPv6 in Hardware Pros Predictable performance Performance under load (or during an attack) Cons Most (but not all) existing equipment will need totally new hardware to support IPv6 State of the art in hardware-based filtering evolved with IPv4 in mind.

IPv4 Filtering Assumptions To filter on any field in the L3/L4 header: Look at a fixed offset into the packet Match based on the bits you find at that offset This model breaks in the presence of IP options Most (all?) network operators drop all IP-option packets anyway

IPv6 Filtering IPv6 uses extension headers An arbitrary number of extension headers can be chained together Header fields are no longer always in the same place Hardware filtering technology designed for IPv4 can’t cope

So what can current HW do? The IP header is always in the same place Source address Destination address Class of service Flow label Packet length Next header

So what can current HW do? If there are no other extension headers TCP, UDP, ICMP, ESP, AH, etc. header will be next These headers are now in a predictable location If there are other extension headers There is no way to find the TCP, UDP, or ICMP header. What do we do? Permit the packet Drop the packet

Extension Headers Hop-by-Hop Options Header Routing Header Used for router alert. Specified as an IP option in IPv4 Not widely used in IPv4 Routing Header Used for source routing

Extension Headers Fragment Header Destination Options Header IPv6 fragmentation is only done by the sending node Sender really should use PMTU discovery Effective PMTU discovery obviates fragmentation Destination Options Header Only defined option is padding the packet to a 64-bit boundary

Drop packets with Extension Headers? IPv4 IP-Options packets Require extra processing by routers Can’t be filtered in hardware None of the defined options are widely used Most network operators simply drop them IPv6 Extension headers Doomed to a similar fate?

Practical filtering of IPv6 Near Term Network operators will drop all packets with extension headers Normal filtering is possible Longer Term A “killer app” would be required to rejuvenate interest in using extension headers Barring this, I don’t see how extensive effort would be expended to support extension headers

Thank you! eater@juniper.net