[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: some questions as to focus for pfkeyv3.


I agree that the changes should be kept to a minimum and that the extensions
should be pulled into PF_KEY.

>    -> do we really need the multicast nature?
>    -> do we really want to define a wire-format vs a C-API?
A student of mine is working on a project, which showed us that the "almost
wire-format" of PF_KEY has some advantages. One advantage is the platform
independence. (e.g. only very little native code is required for a Java
PF_KEY implementation).
> e) look at NPForum's IPsec API, and consider how to deal.
It seems to me that this API does only cover a limited set of scenarios -
nested tunnels are not supported and IPsec can only be implemented by means
of interfaces.

> f) look at Forces.
RFC3746? Or do you mean something else?


Dipl.-Inform. Lars Völker <Lars.Voelker@xxxxxxxxx>
Institute of Telematics, University of Karlsruhe
Zirkel 2, 76128 Karlsruhe
Phone: +49 721 - 608 6397
Fax:   +49 721 - 608 6789