[Nfd-dev] NDN through NATs

[Christos Papadopoulos]

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/
>>     <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
>>     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> 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/20170409/f8cd03d1/attachment.html>