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.
100%
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.
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?
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.
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.
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
Updated by Davide Pesavento over 6 years ago
Davide Pesavento wrote:
Are you saying to have
TcpChannellisten 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?
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.
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?
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.
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?