Project

General

Profile

Actions

Feature #4546

closed

Configurable subnets of IP addresses for "local" TCP faces

Added by Alex Afanasyev about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
Faces
Target version:
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 #1

Updated by Junxiao Shi about 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 #2

Updated by Alex Afanasyev about 6 years ago

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

Actions #3

Updated by Davide Pesavento about 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 #4

Updated by Alex Afanasyev about 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 #5

Updated by Alex Afanasyev about 6 years ago

  • Description updated (diff)
Actions #6

Updated by Davide Pesavento about 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 #7

Updated by Alex Afanasyev almost 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 #8

Updated by Alex Afanasyev almost 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 #9

Updated by Junxiao Shi almost 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 #10

Updated by Davide Pesavento almost 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

Also available in: Atom PDF