Darren Reed wrote:
Can the infrastructure being put in place for the IP tunneling project be
easily leveraged to build tunnels for the following protocols?
* L2TP
* GRE
* PPTP
I suspect these will be new Nemo MAC plugins.
Yes, they would separate MAC-Type plugins.
Can these be implemented as seperate kernel modules in Solaris?
Yes.
If the start of section 6 is true - "This library will provide a
project-private API" -
does this preclude people outside of Sun from developing against your spec?
People outside of Sun can develop code within the scope of the project
(dladm and ifconfig) and contribute to the project.
How is this useful for someone else with OpenSolaris that wants to
develop a tunnel device driver using this project's framework?
The iptun driver and associated libiptun library introduced by this
project aren't meant in themselves to be extensible by a third party.
The extensibility is in the MAC-Type plugin framework, that allows a
third party to write a MAC-Type plugin and associated driver that makes
use of that plugin.
The API defined by this project is only an administrative API for the
iptun driver, and no other driver. The means by which the third party
decides to manage its driver is outside the scope of the project.
Perhaps what's needed for that to be possible is a public method of
extending the types of dladm links. Perhaps dladm plugins...
Now if someone wants to extend the capabilities of the iptun driver by
making modifications to it (and to the associated libiptun library and
dladm command), and contributing to OpenSolaris, then that would be
welcome, and would be within the boundaries of the project private
interfaces defined.
As I read it, you're introducing an API for you to use but nobody else,
so I ask what is the point of it being a documented API?
The API won't be documented. The design document contains these details
because it's part of the design of this project.
At this point, the API is useful so that dladm can manage tunnel links
while allowing ifconfig to maintain backward compatibility by using the
same set of management routines. The intent isn't to allow any
additional application to manage tunnels. The administrative model
we're going after is to have dladm be _the_ administrative interface for
manipulating IP tunnel links. The libiptun functions that dladm and
ifconfig use to do their job doesn't need to be made public.
Given how trivial IP in IP should be,
Yes, it should be. With the previous STREAMS based implementation, it
was far from trivial (have you seen tun.c?). Clearview will hopefully
allow the implementation to look as trivial as it should be.
is it worthwhile demonstrating
with source code how to build such a tunneling device driver is?
Code should be the output of implementing this design, so I sure hope
I'll have some for you in the near future. :-|
This
maybe a completely seperate document, but the idea is heavily commented
source code so that others can understand what's required to build a
working tunnel driver to work against this project and where they should
start hacking if they want to "change something", like the encapsulation.
Sure, I'm all for well-documented code.
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
