On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard <[email protected]> wrote: > On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: > > A solution might be to have a mode where a router may just ignore all > > headers except the src/dst-ip and simply forward all packets, trusting > > that the conversing adults will sort out problems with unknown/new/ > > experimental headers or with a tortured ordering of headers (for > > instance). > > Glad to hear you say that, because that's exactly what RFC 7045 > envisions as the default forwarding behavior: > > I'm glad I'm not too nuts :)
> Any forwarding node along an IPv6 packet's path, which forwards the > packet for any reason, SHOULD do so regardless of any extension > headers that are present [...] > > this does mean that: "please filter the flarbly protocol traffic, eh-1234" is going to be very hard to do in the network. > Recognizing that processing of Hop-by-Hop Options in the fast path is > costly, RFC 8200 formally dropped the requirement for every router to > process them by default: > > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the > Hop-by-Hop Options header if explicitly configured to do so. > > it's important to note that some platforms can't look beyond a certain number of headers, and that ordering of the headers us up to the src, which when they are being mean is ... bad :( Even platforms that can look more than a few headers deep pay for that with clock cycles, so 100g -> 400g -> 1tbps interfaces are less and less likely to see further into the packet(s). > What some of us would like to see is a statement in the draft that it's > just fine to operate this way (Christian Huitema made that suggestion > earlier in this thread, and so did I in my detailed last-call comments). > > oh, good. I like that idea... noting that: "makes filtering bad traffic pretty impossible" though. > Mike Heard >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
