16 May
2013
16 May
'13
7:43 a.m.
On 05/16/2013 01:00 AM, Gioacchino Mazzurco wrote:
On Wednesday 15 May 2013 22:13:10 Axel Neumann wrote:
we discussed two feature requirements for bmx6
1) the support of bidirectional tunnel (currently bmx6 uses two
unidirectional (one-way tunnels) for
gw and network (anycast like) routing over the unicast end-to-end
routing between each gw-client to gw peer.
These tunnels are setup on-demand (only when gw-client's user traffic is
send) and
a benefit here would be that gw-client nodes could trigger the setup of
these tunnels in both direction
and according to the best path perceived by the client.
2) to support virtual (overlay) links on top of an existing network by
specifying a remote ip address instead of a interface for meshing.
This way, it would be easily possible to interconnect clouds that have
no direct link between each other (eg over the internet, similar to what
tinc or other VPNs are doing).
Both features require to react on certain ipv6 header and icmp packets
that are send by other nodes but would normally not be delivered to the
bmx6 process.
Libpcap would allow to capture those packets and let the bmx6 daemon
react respectively.
/axel
Also consider that bmx6 soon will (very likely)
also have a dependency
on libpcap.
It'll be needed for example for the two-way tunnel support that we
discussed in the WCW
and seems the most convenient way to capture packets that indicate that
such a tunnel
was set up or is needed from any tunnel-client node.
I missed that feature
discussion, can you explain in what it consist ?