[Nfd-dev] NDN through NATs
Christos Papadopoulos
christos at colostate.edu
Sun Apr 9 18:00:03 PDT 2017
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>
More information about the Nfd-dev
mailing list