Re: Request for Geneve DLT type

[Michael Richardson <mcr () sandelman ca>]

Guy Harris <guy () alum mit edu> wrote:
    >> I'm working on implementing support for Geneve in libpcap, which is
    >> documented here: http://tools.ietf.org/html/draft-gross-geneve-02
    >>
    >> Geneve is a tunneling protocol than can encapsulate many different
    >> things - normally this would be Ethernet, IP, or IPv6 but it can be
    >> anything with an EtherType. I would like for filters that appear after
    >> the Geneve keyword to apply to the inner payload, i.e. geneve && ip.
    >>
    >> Since the inner protocol is no longer the same as the outer wire
    >> format, the checks that are done on linktype don't really make sense
    >> at that point. The easiest solution would seem to be to allocate a new
    >> DLT for Geneve and change to that when processing the inner header, so
    >> I'm requesting a new type for that purpose. I realize that this is a
    >> little weird because it's not actually a format that will ever appear
    >> in pcap files and could also be handled purely internally (similar to
    >> the is_pppoes variable). However, having implemented it both ways, it
    >> definitely seems cleaner to have a new type that fits into the
    >> existing switch statements rather than a bunch on one-off checks.

    > Having a placeholder DLT_ type that doesn't actually correspond to
    > anything you get from an interface, and a corresponding LINKTYPE_ value
    > that won't ever appear in files, definitely doesn't seem at all clean
    > to me; it's using DLT_/LINKTYPE_ values for a purpose completely
    > different from the purpose for which they are intended.

I wonder if Jesse's proposal might actually make sense, and provide an
interesting way to strip layers of encapsulation.
i.e. in the MPLS and PPPoE cases, one might want to have a way to peel
     the outer encapsulation off, leaving only the IP encapsulation.

We also had the case earlier where we allocated the DLT type to upper-layer
(TCP-after-TLS-mostly) traffic.

Expressing filters for matching encapsulated traffic are difficult to write.
I don't think we can, for instance match port-80 traffic that is PPPoE
from L2TP session 1234, and encapsulated in VLAN 97.

What if we actually modelled this as a pipeline of sorts:
     tcpdump -i eth0 -w - --decapuslate vlanid=97 | tcpdump --pipe l2tp ...|

Except that we might also be able to write it as:
     tcpdump -i eth0 -w - --decapuslate vlanid=97 \| 2tp ... \|

??
What do you think?
(Maybe not today)

    > I will see whether the handling of PPPoE and MPLS can be cleaned up
    > internally to gencode.c; if so, *that* would be the right way to handle
    > Geneve.

I agree that they should all be handled the same way.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on rails    [

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