Internal scan of rfc6598 using --no-private-ipv4

[xlc]

Original issue paritytech/substrate#9922

This happened to one of our collator node.

is_global is including Shared Address Space (100.64.0.0/10) which causes the problem.

We need to either have a generalized way to specify the ranges to block, or have another flag to block shared address space, or explicitly block it when no-private-ipv4 is enabled

[bkchr]

CC @paritytech/networking

[altonen]

We could introduce another flag --only-global-ipv4 as suggested here which filters out a whole bunch of addresses. That seems more natural than patching --no-private-ipv4 to include Shared Address Space

[dmitry-markin]

That's interesting, because the docs and sources of ip_network::Ipv4Network::is_global clearly say that the Shared Address Space (100.64.0.0/10) is not considered global. And we already use IpNetwork::is_global which uses Ipv4Network::is_global internally for IPv4 addresses when --no-private-ipv4 is specified:

polkadot-sdk/substrate/client/network/src/discovery.rs

Line 580 in de71fec

Some(Protocol::Ip4(addr)) if !IpNetwork::from(addr).is_global() => false,

What exactly is the problem with the collator node? Should the IPv4 shared address space be included or excluded from the connection attempts? Becasue right now --no-private-ipv4 flag behaves exactly as the proposed --only-global-ipv4.

[xlc]

yeah I read the docs wrong. Right now it should work. Let me double check the logs and service provider.