[Ns-developers] Node "protocol handlers": limitations

[Gustavo Carneiro]

In Linux "netfilter hooks", each hook is allowed more flexibility to drop or
allow a packet to continue:

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html

>From the article:

> """Kernel modules can register to listen at any of these hooks. A module
> that registers a function must specify the priority of the function within
> the hook; then when that netfilter hook is called from the core networking
> code, each module registered at that point is called in the order of
> priorites, and is free to manipulate the packet. The module can then tell
> netfilter to do one of five things:
>
>
>    1. NF_ACCEPT: continue traversal as normal.
>    2. NF_DROP: drop the packet; don't continue traversal.
>    3. NF_STOLEN: I've taken over the packet; don't continue traversal.
>    4. NF_QUEUE: queue the packet (usually for userspace handling).
>    5. NF_REPEAT: call this hook again.
>
> """
>

NS-3's hooks are relatively more simplistic:

  /**
   * A protocol handler
   */
  typedef Callback<void,Ptr<NetDevice>, Ptr<Packet>,uint16_t,const Address
&> ProtocolHandler;
  /**
   * \param handler the handler to register
   * \param protocolType the type of protocol this handler is
   *        interested in. This protocol type is a so-called
   *        EtherType, as registered here:
   *        http://standards.ieee.org/regauth/ethertype/eth.txt
   *        the value zero is interpreted as matching all
   *        protocols.
   * \param device the device attached to this handler. If the
   *        value is zero, the handler is attached to all
   *        devices on this node.
   */
  void RegisterProtocolHandler (ProtocolHandler handler,
                                uint16_t protocolType,
                                Ptr<NetDevice> device);

Unfortunately each "protocol handler" simply receives a copy of the packet,
but has no power to veto the original packet traversal up the stack (read,
to the remaining hooks).

I am a bit unhappy about this situation.  Things have been mostly working so
far, but I can easily imagine a situation where things might break because a
packet is received by my hook but it continues up the stack and IP also has
a route for it, and so two copies of the packet may end up being forwarded.

I am not asking to support a full netfilter framework in NS-3 (not yet,
anyway ;), but I would be willing to cook up a patch to make "protocol
handlers" return an enumeration telling the node what to do with the packet:
continue or drop.

Would this sound OK?

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert