On (2014-01-09 16:47 -0800), Han Hwei Woo wrote: > I believe you're looking for next-header > > e.g. set from next-header tcp
I know this is known already to many, but I still feel it's important to keep reminding. 'next-header tcp' is different thing than 'protocol tcp'. 'next-header' strictly verifies static byte place in ipv6 header and what it says, if you carry EH, it does not say TCP, and the match is negative, even though ultimately EH tells next-header tcp. This means you must not build FW filters like this 1. permit smtp/tcp to my.smtp.server.com 2. deny smtp/tcp to all 3. permit rest The key here is 'permit rest', these kind of FW must not exist in Juniper in IPv6, as all subsequent L4 'deny' statements can be bypassed by inserting single EH, causing deny to not match, falling to ultimate permit statement. Far end server will be able to parse EH and will treat the packet as normal TCP header. This is not inherently so, JNPR can fix this in devices like Trio/MPC if there is sufficient business motivation to do so. I'm not blaming JNPR, IPv6 was designed in an era where HW implementation was not consider, making it in many ways very badly scaling/insecure protocol when implemented in HW (SLAAC, L2 mcast snooping, EH) -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
