an IP class set feature idea
phil-news-nospam-2004-10-13-1610_at_ipal.net
Date: 10/13/04
- Next message: John Fusco: "Re: gettimeofday ticks backwards"
- Previous message: Eric: "can i capture control-scroll-lock to a file?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 13 Oct 2004 21:10:28 GMT
I've been thinking about this idea for some time now, and thought I'd
go ahead and throw it out to see what kind of feedback (good and bad)
I might get. I hope that the feedback is clear at least as to whether
it is a technical issue or a social issue that it refers to.
The origin of this idea comes from wanting to be able to make changes to
what IP addresses are filtered in some IP filtering logic without having
to change, or even know, what the sequence logic of the filtering rules
are, nor to have to worry about reconstructing the sequence, nor to
worry about the size of the sequence when I have a lot of IPs that need
to be filtered.
But I think this concept could be used more broadly, such as in the IP
address being used to bind a socket to listen to.
The idea is to take a few special IP addresses that won't normally be
used, and define them to be a set of special "IP classes". My thought
is to take some IP addresses in the range 0.1.0.0/16 for IPv4 and apply
this new semantic. For each such IP address, the kernel would hold a
set of IP addresses or IP address ranges (with subnet prefix length)
that can be configured via a /proc entry, which can also be used to see
what has been configured.
The choice of 0.1.0.0/16 is arbitrary for the moment. If there are
technical conflicts with this range, maybe some other can be found.
It would have to be a range for which there would be no sensible use
of that IP in any other context. Doing this for IPv6 might be done
by having another set of address in IPv6 address space, possibly even
the IPv4-in-IPv6 addresses for whatever is used in IPv4 space.
How it can be used:
When an IP filter is configured with one of the 0.1.X.Y addresses to be
matched, the logic used to match a packet under test would detect the
leading 0.1 in the IP in the filter rule, and divert to some code to do
the matching against the IP class. That code would check the IP from
the packet being passed to it, and see if any of the configured ranges
is a match for the given IP under test. A boolean is returned, and the
IP filter logic will treat that as if it had merely compared the IPs in
the normal cases.
The benefit to IP filtering is that programs can quickly add and delete
IP addresses and ranges in one or more of these classes (the X.Y part
being the identity of one of 65536 possible classes) on the fly, such
as for short term block or diverting of packets according to the rules.
Further, if the number of addresses is large, this can provide for a
means for faster matching (presumably lookup code would be as fast as
similar code used for routing table matching, if not even using that
very same code).
When a socket is bound to one of the 0.1.X.Y IP addresses for listening,
an incoming packet will be tested first to see if it matches any normal
listen bindings, and if none, then it will be tested against these IP
classes to see if there are matches there.
The benefit to binding to IP classes like this is that programs which
are only designed for binding a single IP address, can be made to work
on multiple IPs, but not have to work on every IP as 0.0.0.0 would do
(but otherwise the behaviour would be similar to binding to 0.0.0.0).
Further, which IPs will be associated with such a binding to one of the
IP classes can be changed on the fly without having to restart that
program or otherwise get it to rebind a new socket. Rules would have
to be made to define behaviour with respect to overlaps between IP
classes (such as simply defining it as unspecified behaviour, meaning
it might match any of the classes first).
While having masses of IPv4 addresses on a single machine would not be
common, doing so in IPv6 address space might be more common.
A special reverse mapping cache could be used for this to speed up
matching an incoming packet to the appropriate socket.
I could imagine routing could make use of this as well.
An implementation would certainly have to have hooks in all the right
places. The IP lookups in the classes could work like (and maybe use
the same code as) routing table lookups.
OK, so what would this break?
Or what would it fix?
-- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------
- Next message: John Fusco: "Re: gettimeofday ticks backwards"
- Previous message: Eric: "can i capture control-scroll-lock to a file?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
