Re: BPF Extended: addressing BPF's shortcomings

[Darren Reed <darrenr () netbsd org>]

On 11/06/2015 1:08 AM, Paul "LeoNerd" Evans wrote:
> On Wed, 10 Jun 2015 23:17:20 +1000
> Darren Reed <darrenr () netbsd org> wrote:
>
> > BPF & IPv6
> > ----------
> > The problem with IPv6 and BPF is that the transport header (TCP,
> > UDP, etc) can have a number of extension headers between it and
> > the network header that is present for IPv6. There's no hints in
> > the IPv6 header as to how many of these extension headers there
> > are, or how many bytes the extension header(s) take up. This leaves
> > BPF in a precarious situation because it cannot be reliably used to
> > match on layer 4 packets. What's missing is the ability to either
> > find a specific header after the IPv6 network header or just to
> > determine what the last one is.
> ...
>
> If you're considering extending BPF to better suit IPv6, have you seen
> either of my proposed ideas?
>
>   1) Add a LOOP instruction that allows certain kinds of
>      backward-directed jumps, in order to efficiently implement the IPv6
>      header-chain walking without needing manual loop unrolling, while
>      still giving static guarantees about eventual termination of the
>      program.

I haven't seen much of an appetite for any sort of loop construct in any
of the changes or discussions around BPF. Anywhere. It is often brought
up but always the point of a BPF program being easily verified is mentioned.

>   2) A few more AD constants added to the Linux "auxdata" area, giving
>      information about the transport layer.

Can you please expand on this?


Darren

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers