[Nfd-dev] NDN through NATs

[Dehart, John]

Christos,

I don’t know for sure in each case why some sites use a NAT.
I suspect it is a combination of lack of IP address and lack of institutional
authority to get the network configuration you want.  Some sites have a very
centralized network authority and it is hard to get anything outside their norms.

John

On Apr 9, 2017, at 8:00 PM, Christos Papadopoulos <christos at colostate.edu<mailto:christos at colostate.edu>> wrote:


Hi John,

As you point out the restriction was there to ease management. If management can be done through a NAT then I suppose we could allow exceptions under situations such as those you describe below.

I am still not entirely comfortable with NATs since they add another layer to be configured properly and a dependence on another machine. But if you feel comfortable with them then I have no objection.

Just curious, is there a good reason why they want to put a testbed machine behind a NAT? Is it lack of routable IP addresses or something else?

Christos.


On 04/09/2017 05:10 PM, Dehart, John wrote:

Alex,

The site still has to be configured so that we get ports that are acceptable.
Perhaps we don’t get external port 80 but our end can use alternate ports.
We have one site where we don’t get port 80 but we use port 8080.
There is another site where we don’t get port 22, but they have configured
external port 22222 to get translated to port 22 on the site node behind the NAT.

So, it is not automatic. There is configuration needed at the site end and
at our end.

It is perhaps not ideal but it is manageable.

John


On Apr 9, 2017, at 5:33 PM, Alex Afanasyev <aa at CS.UCLA.EDU<mailto:aa at CS.UCLA.EDU>> wrote:

How would you manage such a node?  If it is behind the NAT (without any ports redirected, then it will only be able establish connectivity to the testbed and there could be issues getting status (from web interface).

--
Alex


On Sun, Apr 9, 2017 at 3:12 PM, Dehart, John <jdd at wustl.edu<mailto:jdd at wustl.edu>> wrote:

All:

In our policy statement (https://named-data.net/ndn-testbed/policies-connecting-nodes-ndn-testbed/)
for a site joining the NDN Testbed, we state:

"The machine may be a dedicated physical box or a virtual machine (VM) with a
  publicly routable IP address (i.e., should not be behind a NAT). “

I would like to lift the restriction about being behind a NAT. I believe that we originally put
that stipulation in the policy as a convenience to us as we managed the NDN Testbed.
We have already been flexible with a couple of sites that wanted or needed to be behind a NAT.
So far, I do not have any evidence that this has caused any problems. We do have an issue with
one site that happens to be behind a NAT but at this time I do not think the NAT is causing the problem.

Does anyone have any concrete reasons why an NDN node on the NDN Testbed should
NOT be allowed to be behind a NAT?

Thanks,
John


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev






_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170410/d8b1ced3/attachment-0001.html>