Re: New network implementation proposal [was: Re: ipv6 on hurd]

[Niels Möller]

Olivier Péningault <peningault@free.fr> writes:

> le ven 25-10-2002 à 10:25, Niels Möller a écrit :
> > Sure, but do you really want them to run fully separately? It's common
> > (although not required by any standard, afaik), that an ipv6 socket
> > bound to the ipv6 wildcard interface should be able to accept ipv4
> > connections.
> ... Then, it is the responsability of human to decide on which
> interface(s) the program will bind.

I suspect your missing my point. An applications wants to bind the
ipv6 wildcard address, and have that automagically include the ipv4
wildcard address. When a ipv4 connections arrives, the accept() on the
ipv6 should return the ipv4 connection, with addresses represented as
ipv6 "mapped" addresses. What component will do this mangling?
Probably pfinet/hurd-net is the right place (unless you do all the
work of bind in the user process).

> I don't agree. According to RFCs, arp is a generic protocol wich allows
> many layer 3 protocols to find data link addresses. It is not limited to
> ethernet/ip.

Which media, besides (the several flavours of) ethernet use arp? In
any case, I think the natural way to share arp code is to put it into
a library, no extra translators needed. To replace the arp code, the
user of course will have to replace the server that links to the arp
library, but I don't think that's a problem.

> arp has to know each layer 2 interface (maybe they will have a way to
> register themselves)

Why? All interfaces should have an associated network address and
netmask, so given an ip address you want to reach, you always know on
which interface to send an arp request. The exception being multiple
interfaces to the same link, I'll have to think some more about that
case. THe point is that I think of arp as a purely link-local thing.

> > But in
> > order to do tcp, tcp, ip and icmp are used together. I'm all for code
> > separation, but I'm afraid that putting the implementations into
> > separate *processes* will just add unnecessary complexity to the
> > system, for no real gain.
> This is a complex problem. We can offer nice features, but where do we
> stop ? Which feature are more important than efficiency, and when must
> we privilege efficiency against features ?

Start *simple*. Don't implement the complexity until the day you're
going to implement the particular feature that depends on it. (I admit
I've read one or two xp books ;-)

> I know that hurd-net has issues, this idea is a way to hide the fact
> that hurd-net is not replaceable.

My gut feeling is that what you call "hurd-net" should replace pfinet,
and that it should be as hard or easy to replace as pfinet. I don't
understand why you can't run several networking stacks in parallell.

> I thought about these problems, and that's why I proposed to have a
> "central" translator to solve this...

It doesn't have to be central to solve these problems. Each instance
of pfinet will have it's own ip-addresses, and manage ports for those
addresses. The allocation of ip-adresses is a netadm problem, how
do you prevent two different machines to try to use the same ip
address? It can't be pfinet's responsibility.

And if yu bind the wildcard address, you will naturally end up
listening on all interfaces managed by your chosen pfinet (or do some
hacking to access several pfinets in parallell).

> I will think a lot about it this week end, I will read code and books,
> and maybe I'll can propose an updated version of my point of view about
> network re-implementation

I'll try to get the time to sketch out what I think the interfaces
should look like, in a separate mail.

/Niels