2009/11/12 Rémi Denis-Courmont <[email protected]>: > > On Thu, 12 Nov 2009 11:25:59 +0100, Alan Davy <[email protected]> wrote: >> The point of our proposed solution is to specify a common set of rules >> or guidelines for managing the entry of data into the hop by hop option >> header data field. The hop by hop option can be ignored by routers that >> do not support it or blocked by edge routers that do not like/recognise >> it. > > I wonder how that is possible. Middleboxes want to find the transport > header, and often don't like in-band data that they don't understand (think > of NATs and firewalls). Also hardware is often optimized for the case that > there is no hop-by-hop header. If there is, I understand in many cases, > packet processing will go through "slow path".
(rja will beat me for this, but..) if you can't predict what's at byte-offset X ... you have to punt to 'slow-path' (out of asic-land and into cpu/software land) to make a decision, of skip processing that packet. 'skip processing' could mean 'drop on the floor' or 'pass on through'. hop-by-hop options are a nasty can of worms. (variable length headers really) > It's irrelevant whether your extension can be safely ignored - it will > still incur some processing overhead in any case. And *I* am only answering > your question why many people do not like HbH. I am not a network gear > vendor or operator myself. operations folk don't like things they can't control (easily) stealing resources from their gear, and/or non-deterministic behaviour "oops, 1kpps of hop-by-hop causes the cpu to hog out, which causes isis to drop which causes bgp nexthops to disappear, which causes..." sure, some of this could be ameliorated with better scheduling or other bits, but... just not doing this is 'safer' for the gear. I suspect HbH options will just get skipped (by config option) in gear so an operator can decide to process these (on a less constrained platform/network) or ignore them believing that whatever the HbH option is it's not relevant to transit traffic. -Chris -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
