Project

General

Profile

Actions
Copy link

Feature #4546

closed

Configurable subnets of IP addresses for "local" TCP faces

Added by Alex Afanasyev over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Alex Afanasyev
Category:
Faces
Target version:
v0.7
Start date:
Due date:
% Done:

100%

Estimated time:

Description

This is a user request that uses NFD with containers: app and NFD are in different local containers not using 127.0.0.0/8 address space.

Actions
Copy link
 #1

Updated by Junxiao Shi over 6 years ago

Docker (and probably other container technology) allows sharing a Unix domain socket between containers. Is there any reason not to use a Unix domain socket?

Actions
Copy link
 #2

Updated by Alex Afanasyev over 6 years ago

It is not about docker, but specialized containers. It is impossible to use unix socket in the target environment.

Actions
Copy link
 #3

Updated by Davide Pesavento over 6 years ago

  • Start date deleted (03/12/2018)

Are you saying to have TcpChannel listen only on specific IP addresses? That has been on my todo list for a while, but lacked a use case for it.

Actions
Copy link
 #4

Updated by Alex Afanasyev over 6 years ago

  • Subject changed from Configurable ranges of IP addresses for "local" TCP faces to Configurable subnets of IP addresses for "local" TCP faces
Actions
Copy link
 #5

Updated by Alex Afanasyev over 6 years ago

  • Description updated (diff)
Actions
Copy link
 #6

Updated by Davide Pesavento over 6 years ago

Davide Pesavento wrote:

Are you saying to have TcpChannel listen only on specific IP addresses? That has been on my todo list for a while, but lacked a use case for it.

Alex answered my question during today's NFD call. The answer is no, the current listening behavior works fine and faces are created correctly, but they are considered "non-local". This task proposes to add a whitelist of IP subnets, instead of the hardcoded is_loopback() check, which would make the created face "local".

I suppose the whitelist would be specified in nfd.conf. @Alex, can you suggest a syntax?

Actions
Copy link
 #7

Updated by Alex Afanasyev over 6 years ago

  • Assignee set to Alex Afanasyev

Here is my proposal for nfd.conf update:

  ; The tcp section contains settings for TCP faces and channels.
  tcp
  {
    ; ... existing stuff    

    ; Whitelist/blacklist of IP address ranges to be considered "local"
    local {
      whitelist {
        subnet 127.0.0.0/8
        subnet ::1/128
      }

      blacklist {
      }
    }
  }

I will need to extend a bit NetworkInterfacePredicate and Network to support IPv6 prefixes.

Actions
Copy link
 #8

Updated by Alex Afanasyev over 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

I am a bit struggling on figuring out how to propagate white/blacklist info into the transport, where it is determined the face type. https://gerrit.named-data.net/4649 adds preliminary code to process config file. But I don't see a clean way to pass a structure inside the factory into the transport. Any suggestions?

Actions
Copy link
 #9

Updated by Junxiao Shi over 6 years ago

how to propagate white/blacklist info into the transport

TcpFactory creates a function object std::function<FaceScope(const FaceUri&)> determineFaceScopeFromRemoteFaceUri, and passes it down to TcpChannel and TcpTransport via constructor parameter.
TcpChannel stores the function object by value (in practice there are at most two copies), so TcpFactory does not have to retain it.
TcpTransport invokes the function and takes its result, but does not store it.
The same function object shall survive even if TcpFactory reloads its configuration.

Actions
Copy link
 #10

Updated by Davide Pesavento over 6 years ago

  • Category changed from Management to Faces
  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

All done here I guess?

Actions
Copy link

Also available in: Atom PDF