On Tue, Dec 4, 2018 at 7:56 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 2018-12-05 12:23, Christopher Morrow wrote:
> 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.
Yes. But extension headers were explicitly defined to be from end system
to end system, not for middleboxes. So that difficulty was designed in.
sure, that's all well an good, but when 1mpps of eh-1234 show up on your door... uhm, you're going to want "relief" :)
speaking from experience ... you really will want your ISP/carier/transit/peer to help you NOT get lit on fire.
Them saying: "Well I COULD do that... but ... no, sorry I'm just the bit carrier, have fun!"
is going to go 'not well' (again, having had this conversation, though not about ipv6 extension headers).
>> 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).
Yes. The IPv6 header was designed so that all the information needed for
*forwarding* was at the front. The extension headers were designed on
the assumption that they would be analysed by a CPU, not by an ASIC
or FPGA, so that the linked-list model seemed fine.
I think people believed that endpoints would take over DPI
filtering: https://www.cs.columbia.edu/~smb/papers/distfw.pdf
HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and coming nx400G ... there's just not a reasonable story for "dpi" there. (I suppose: "yet" and "without paying the approximate value Coca-Cola Companies yearly advertising budget")
-chris
Brian
>> 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
>>
>
