Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> At the level where ip address is registered ip port can be registered as well.
> The ip header has to be analyzed to determine ip address and that makes it
> easy to check the port at the same time.
Perhaps I should read the ip specs again, but my understanding is that
the layer 3 code would process the ip header and ip options, and the
type of the upper level header, but regard everything after that,
including the rest of the upper level header, as packet contents.
I'll try to argue my point some more.
Say you add esp processing, then the esp process would talk to the
layer 3 code, and present itself to the layer 4 in the same way as
plain unencrypted layer 3 (exactly how one should do that I don't
know, having separate ipsec0: interfaces is one way).
If you keep knowledge of portnumbers in the transport, layer 4, code,
then neither plain layer 3 nor esp code need know about it. On the
other hand, if you define the layer three interface such that the code
below it needs to know port numbers, then you have three modules that
need to deal with them rather than only one. One could of course share
some code in some library, but I don't quite like this diffusion.
And if you add more transport protocols (I'm not familiar with that
area, but as I understand it there are several new experimental
protocols that people are working on), then the layer three code, both
plain and esp, needs to know about all of them. Perhaps you're lucky
that all or most protocols use a 16 bit portnumber in exactly the same
position in the transport header, but it seems quite ugly to depend on
that. If I were to design a new transport protocol, I wouldn't want
hurd hackers to tell me "you must use a 16 nit port number, and it
must be in the same position in the header as for tcp".
So my preferences are
1. Keep layer 3 clean of portnumbers.
2. If for some reason that's seriously impractical, add a general
method to the interface that lets users filter out interesting
packets based on their contents.
/Niels
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
