Re: Networking design proposal

[Niels Möller]

Michal 'hramrach' Suchanek <hramrach_l@centrum.cz> writes:

> On Wed, Nov 06, 2002 at 02:52:25PM +0100, Niels M?ller wrote:
> > Olivier P?ningault <peningault@free.fr> writes:
> > 
> > > You didn't understand correctly. Layer 2 translator performs ethernet +
> > > arp, not ip !
> If you do not do IP int L2, how can you tell which L3 gets the packet? 

The interface for reading raw ethernet frames should primarily filter
on ethernet type code and ethernet addresses. If there are several
processes (say, two completely independent ip-stacks) that want to use
the same ethernet hardware and the same ethernet address, then the
simplest way is to have the ethernet driver deliver each received
frames to *both* processes.

Or you can do something more clever with filters that look into packet
contents (I've heard that some network cards even has some hardware
support for that), but if you do that I think you want a nice general
interface, and not code knowledge about the inside of ip packets into
the ethernet driver.

> > You also need to understand some of layer 4. If you have a received
> > icmp packet and a bunch of clients, then you need some more
> > information about your clients, like "client 1 sends tcp-packets from
> > address 1.2.3.4" or "client 2 sends udp-packets from address 5.6.7.8,
> > port 47".
> But that is why they register their IPs with L2, isn't it? You need the 
> same for an ordinary ip packet.

They layer 4 code will register the ip addresses it's interested in,
in some way or the other, with the layer 3 code. But I don't think the
layer three code should need to know about port numbers (just like I
don't think the ethernet driver should need to know about ip
addresses). In both cases a general interface for matching packet
contents would be nice, but it shouldn't be added unless it's really
needed.

> This will be needed for routing. But for packets that are used by
> connections to/from local machine you are usually not interested in protocol
> specific details. But it may be easier to cope with them than designing
> a protocol independent abstraction ;)

I'm not sure I understand this point. For local communication, one
usually either use AF_INET socket and connect to localhost/127.0.0.1,
thus exercising all of the ip-stack except the ethernet card, or use
AF_UNIX sockets.

> I do not completely agree with this. Ip address is just a few numbers, port
> is another number. You may choose to interpret som numbers in one layer and
> other numbers elsewhere. But I do not see any reason for this as the numbers
> are all available at the same level.

All the packet data is available to the ethernet driver, sure. The
problem is not the raw data, but the knowledge (including code) needed
interpret the data. If possible, knowledge of different parts of the
chain should be isolated to separate processes.

> As for generating icmp packets: It is not very consistent if some program
> generates host-unreachable and other connection-refused. But with your 
> separation of ip:s from ports the knowledge about ip and port is divided 
> unneccessarily.

I don't see that as a problem. In fact I would expect the generation
of host-unreachable and connection-refused to usually happen at
different *machines* (the destination of my packets, and some router
on the (broken) path across the network, respectively). So having them
sometimes be generated by different processes on the same machine
doesn't seem odd to me at all.

Regards,
/Niels