Erik Nordmark wrote:
> Darren Reed wrote:
...
>>> There were concerns raised that the lack of a general-purpose hook
>>> mechanism (despite the claims that there is already such a
>>> mechanism, it
>>> doesn't appear to be the case) is leading to exploding complexity in
>>> the
>>> IP implementation. Erik noted that the existence of a general-purpose
>>> hook mechanism would not necessarily address the complexity problem due
>>> to the sensitive nature of the interactions between the different hook
>>> consumers.
>
> That was only one of my points.
>
> We have several cases when we use hard-code code paths to plug in
> different functionality in IP. IPsec is a good example of that. One
> could in principle argue that IPsec should have used a "generic IP
> packet hooks" interface instead of hard-coding callouts from IP to
> IPsec. But I think we did the right thing there, since IPsec is quite
> an integral part of the IP layer and we need a tight and evolving
> coupling between the two.
>
> I also pointed out in the meeting that we might implement future
> things that would likewise benefit from hard-coded callouts. Mobile IP
> and shim6 are things that it wouldn't make sense to implement using
> some generic "IP packet hooks" framework, for the same reasons that
> IPsec doesn't fit.
>
> I think L3/L4 LB fits in the same category even though its
> interactions with IP is currently simpler than e.g., IPsec or MIP.
I disagree... IPsec and Mobile IP/shim6 are integral features of the IP
protocol suite
and the way in which they need to be handled should reflect this, which
is to say that
I agree with how they're treated today.
Load balancing is not in the same category.
Whilst load balancing does need to sit at a very particular point in the
code path
for IP packets, it's interaction with IP and its role are distinctly
value-add rather
than basic functionality needed to interoperate with other systems - as
is the case
with NAT.
> If we look at the micro-architecture of ip_input() we see that one of
the things it needs to
> do is to determine the next-hop of the packet. This is determined
from a source route
> option or the IP destination field.
>
> An L3/L4 LB affects this. In particular, when doing DSR i.e. the
> packet is not modified, this is the only effect the LB has; the
> nexthop is determined from the LB decision. But that
> micro-architecture has to be such that we get predictable behavior
> when combined with a 1) source route option and/or 2) a pfhooks user
> which NATs the packet.
> Hence the order is critical.
I agree with this.
>> If the general purpose mechanism isn't general
>> purpose enough then it behooves us to document
>> what its failings are and try to improve it.
>
> I do think we should document the issues of how to use pfhooks for
> packet filter and NAT. But I don't think we should try to
> incrementally turn it into something it wasn't intended to be ("IP
> hooks").
Hmm, I'll follow up with you on this out of band..
> FWIW I've told you of some of the issues a while back.
> 1. It isn't clear which hook entrypoints the hook user can modify the
> packet and have IP take notice (e.g., to route it based on a changed
> destination.) I think we should just document that this can only be
> done for "physical_in_event".
> 2. It would be good of the result of the hook was different when the
> packet was modified as opposed to passed through unmodified, since
> that would help detect incorrect cases of #1 and also allow
> optimizations in ip_input.
(1) should be captured on a man page, but which one?
(2) sounds like something meaningful that can, at the very least,
be put into an RFE - see 6781115.
> 3. Having multiple consumers on the same hook where more than one of
> them modify the packet seems problematic. I don't know if we have any
> cases where folks want to do this,. If we do at least the order is
> critical. But it might also be that user2 needs to be aware that user1
> modified the packet. [My, perhaps incorrect, understanding of Linux is
> that they manage such complexity by having iptables be the only user
> of the hook and which allows them to extend and modify iptables to do
> that ever they need. Hence they can avoid ships-in-the-night
> modifications of the same packet.]
Linux does allow more than just iptables to hook in,
however the method they choose to determine the order
in which a packet is received (assignment of priority
numbers for the various "hooks") was rejected by PSARC.
iptables provides the NAT/firewalling for Linux. You should
also have a look at what they call "netfilter" as it is "netfilter"
that provides the infrastructure in Linux for iptables to use.
So the ships-in-the-night problem is definately present there,
as well as everywhere else that I've seen, too. But as long as
the relative ordering of multiple consumers is correct and
stable, then it shouldn't be necessary for others to be aware
of someone else having made a change (or that will make one.)
Darren
