[Fedora-nightlife-list] NAT traversal

[Renato Figueiredo]

On Tue, Jun 17, 2008 at 4:48 PM, Matthew Farrellee <mfarrellee at redhat.com>
wrote:

> Renato Figueiredo wrote:
>
>> It's great to see this project getting off the ground!
>>
>> Our group is very interested in this idea. We have been working with
>> wide-area VM appliance Condor pools for a couple of years and have
>> developed
>> a peer-to-peer virtual network (IP-over-P2P, or IPOP) that supports
>> decentralized NAT traversal with techniques including hole-punching and
>> proxying. We've found this to be very useful to facilitate the deployment
>> of
>> ad-hoc wide-area Condor pools/flocks where nodes are increasingly behind
>> NATs. The IPOP code is also open source and user level (though it
>> currently
>> uses a tap device), so I thought this would be of interest to the list.
>> Here
>> are some pointers for more information (and software):
>>
>> http://grid-appliance.org
>> http://ipop-project.org
>>
>> We're starting a collaboration with the Condor group on a particular
>> application of this virtual infrastructure for computer architecture
>> simulation (http://archer-project.org); hopefully sharing our experience
>> with this system can benefit nightlife and vice-versa.
>>
>> Bests,
>> --rf
>>
>
> Renato,
>
> IPOP is definitely something that could be of use to the Nightlife project.
> Letting NAT'd execution nodes join the network is currently an issue. As
> Nightlife grows it could also become a good testbed for IPOP.
>
> Have you considered packaging IPOP in Fedora?
>
> Best,
>
>
> matt
>

Matt,

Currently we distribute the source code and a binary snapshot. As far as
creating a Fedora package, that shouldn't be difficult at all - the only
dependences we have are the mono C# runtime, the dhcp client, and a tap
device.

The other issue is configuration of virtual IP addresses. That would be a
function of how nightlife is expected to be deployed - e.g. a single big
pool or many smaller pools.  We typically use a private address space for
the tap endpoints and that is within NATed virtual machines -  avoiding
conflicts with the host network. If the tap device is connected directly to
a host, it's important to configure the tap to avoid overlapping private
network address spaces. We can deal with multiple decoupled IP overlays
through IPOP namespaces, but that assumes multiple Condor pools - a node
would join only a pool for an IP range that doesn't conflict with their
private networks.

One idea we have thought about in the context of Condor but have not
implemented is port forwarding instead of IP tunneling, which would not
require a tap device. This requires some more development, unfortunately we
haven't had the cycles to pull this off yet.

Bests,
--rf

-- 
Dr. Renato J. Figueiredo
Associate Professor
ACIS Lab / Electrical and Computer Engineering
University of Florida
http://byron.acis.ufl.edu
ph: 352-392-6430
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-nightlife-list/attachments/20080617/e3d14d24/attachment.htm>