On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard <heard@xxxxxxxxx> 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
