Router alert handling (in integration branch)

[yol]

This pull request includes an updated version of the topic/router-alert-handling branch modified for the integration branch.
See #10, #11

[avarga]

Thank you for the patch! However, could you provide some details why this functionality is important enough to be included in INET? What is the motivation?

[yol]

The motivation is that it is needed for some protocols (in this case, a layer-3 QoS path reservation protocol for a research project at a German university, but as far as I know also NSIS should it get implemented in INET) to be able to intercept IP packets from the network, possibly modify them and set a verdict (accept or drop packet). It could be argued that there should be a more general solution, a complete packet filtering framework. I agree in principle, but this would mean a massive amount of work and is probably not needed for most protocols. The router alert flag is a standardized IP flag that can be utilized for this purpose and using it seemed like a good compromise between too much effort and over-specialization to our needs.

[yol]

See also https://www.rfc-editor.org/rfc/rfc2113.txt for a general motivation and https://www.rfc-editor.org/rfc/rfc5971.txt for its usage in NSIS

[avarga]

When switching to NetFilter hooks, IRouterAlertHandler.cc/h, and IPv4NetworkLayer.ned modifications could also be dropped.

[avarga]

I think it could be implemented with NetFilter hooks for IPv4, but: The project is IPv6 only.
IPv4 router alert handling was only added for the sake of completeness.

I see... How about we take the parts that deal with being able to send Router Alerts (ie. control info and IPv4/IPv6 datagram changes together with handling code), and you keep the handling of received Router Alerts (IRouterAlertHandler, etc) in you project-specific repo? See, there is no use case for router alert handling in INET right now (we don't have NSIS etc); when we implement NetFilter then it will also be suitable for hooking up router alert handling code, so the current IRouterAlertHandler stuff would only be temporary. And for unused temporary code the patch is a little heavy-weight (extra gates, extra modules, etc). But I have no problem with accepting the part of sending router alerts, since it's quite straightforward, nonintrusive, goes in the direction we want INET to go, etc.

[yol]

Sure, we'll definitely go with NetFilter once it lands in IPv6. We'd even help implementing once you say the IPv6 code is stable enough for that to be feasible. Do you have a general outline when this will be the case? With the release of INET 3, maybe?
I think integrating the router alert sending code would be great since it is a quick, easy and standardized way to tag packets for interception. As far as our concerns go though, we would not need it once the NetFilter code is in place. We can distinguish packets that need special handling by other means (UDP port is enough for us).

[avarga]

Regarding the IPv6 code, it's not really about stability, but rather the code is currently ill-structured for maintainability and future extension, it needs to be re-thought and refactored. On IPv4, Tamas Borbely has done similar refactoring in a series of commits starting at 2012-01-19 (you can find it in the repo). It was planned that Tamas does this refactoring for IPv6 too, but he has left our team since then. We currently don't know when we can do IPv6 and who'll do it (we are a very small team, and currently concentrating our efforts on wireless the PHY and MAC layers, and on developing OMNeT++ itself.) It has not been planned for the 3.0 release. Also, some of us will have to dig ourselves into the IPv6 RFCs, as none of the team are exactly IPv6 scientists.

[avarga]

As for actions:

1. We can merge the router alert sending code, once the suggested modifications are done (i.e. the comments added to IPv4ControlInfo.msg and IPv6ExtensionHeaders.msg). Shall I wait for an updated pull request?
2. We can try "hack" the NetFilter support into the current IPv6 code if really needed, although it won't be that pretty. We originally decided to postpone IPv6 NetFilters to after the refactoring because it would be in the way for the refactoring.

[yol]

1. Sure, I'll make a new request. Doesn't hurt to have the RA sending code in there.
2. We can use our patched INET until the IPv6 code is ready for NetFilter, so the issue is not time-pressing. I don't think it's any use adding more functionality at this point if a major rewrite is in the works. If you could just drop me a line when you're finished with that, we'd be happy to integrate NetFilter.