Replies: 6 comments
-
|
Right now, for my own purposes I think I'm going to write some simple rank function, and then select N most promising addresses to keep things under a reasonable limit. Discount ipv6, even more so everything that is local. Possibly iroh should do something like this internally by default as well, to avoid unlucky users like me get in all sorts random issues by software using iroh. Oh, I almost forgot: broadcasting my whole internal networking infrastructure in a ticket I'm sharing seems meh for many reasons. I realize that p2p at least means public addresses being shared, but all private interfaces including VPNs ... 😬 |
Beta Was this translation helpful? Give feedback.
-
pub(crate) async fn iroh_address(&self) -> IrohResult<NodeAddr> {
fn sanitize_addr_info(addr_info: AddrInfo) -> AddrInfo {
fn is_ipv4_cgnat(ip: Ipv4Addr) -> bool {
matches!(ip.octets(), [100, b, ..] if (64..128).contains(&b))
}
let direct_addresses = addr_info
.direct_addresses
.into_iter()
.filter(|addr| match addr {
std::net::SocketAddr::V4(ipv4) => {
let ip = ipv4.ip();
!ip.is_private()
&& !ip.is_link_local()
&& !is_ipv4_cgnat(*ip)
&& !ip.is_loopback()
&& !ip.is_multicast()
&& !ip.is_broadcast()
&& !ip.is_documentation()
}
std::net::SocketAddr::V6(ipv6) => {
let ip = ipv6.ip();
!ip.is_multicast()
&& !ip.is_loopback()
// Unique Local Addresses (ULA)
&& (ip.to_bits() & !0x7f) != 0xfc00_0000_0000_0000_0000_0000_0000_0000
// Link-Local Addresses
&& (ip.to_bits() & !0x3ff) != 0xfe80_0000_0000_0000_0000_0000_0000_0000
}
})
.unique_by(|addr| match addr.ip() {
IpAddr::V4(ipv4) => IpAddr::V4(ipv4),
IpAddr::V6(ipv6) => IpAddr::V6(Ipv6Addr::from_bits(
ipv6.to_bits() & !0xffff_ffff_ffff_ffffu128,
)),
})
.sorted_unstable_by(|a, b| a.is_ipv6().cmp(&b.is_ipv6()).then(a.cmp(b)))
// Limit to 4
.take(4)
.collect();
AddrInfo {
direct_addresses,
..addr_info
}
}
fn sanitize_node_addr(node_addr: NodeAddr) -> NodeAddr {
NodeAddr {
info: sanitize_addr_info(node_addr.info),
..node_addr
}
}
self.endpoint.node_addr().await.map(sanitize_node_addr)
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure what your situation is, though you might want to consider only putting the RelayUrl in DNS. This is what PkarrPublisher does for publishing to a DNS server to use with DnsDiscovery. The relay server does not change as often as all local addresses, which also makes it a bit better suited for the DNS system where you can not control the cache invalidation that well. For connectivity over the internet we generally prefer fully relying on the relay server, hence the "full" addressing information is usually Regarding the privacy issue, unfortunately this is rather unavoidable for p2p. Not publishing your direct addresses means you only expose them to connected peers however, and you can reject connections based on the NodeId. Though note we haven't spent time on reducing privacy leaks to the bare minimum yet. There probably are measures possible to reduce the impact, e.g. filter which addresses are shared with which peers, relay-only connections and some users have even been wondering about double-relayed connections. |
Beta Was this translation helpful? Give feedback.
-
|
With the code I've put above, I only get 3 addresses added to the ticket, at 164 of base64 encoded len, which is OK for my application. I kind of like having some direct connection ability in there, maybe because I'm a hopeless ipv6 enthusiast. Just in case there's a problem connecting to the relay. Though I think it all will largely depend on the given application nature and needs. I think the goal here should be:
Eg. AFAIU |
Beta Was this translation helpful? Give feedback.
-
|
thank you for opening. converting to a discussion, as this is a usage question about tickets |
Beta Was this translation helpful? Give feedback.
-
|
Even with IPv6 there will often be a firewall that may need holepunching. But there certainly are also many situations in which a direct connection without a relay server are possible too! The tradeoffs for what to do by default are tricky: tickets as used by sendme (i.e. just put any possible contact information in there) support all use-cases. But the flipside is that they are only valid at the time they are created. The contact-via-relay system, discovery relay server via DNS is currently our preferred tradeoff and our assumed baseline for connectivity. But there are of course other needs too that applications have. That is why mDNS also exists, that is why tickets exist. If you have any specific pointers as to where some pointers in the documentation would have helped you understand the system and the tradeoffs you have to make that would be appreciated. Documentation always needs improving and we probably don't yet do a good enough job of explaining this. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to put the ticket into a DNS record and the size is becoming a big problem:
I tried to encode as base64 and it comes as 244, when encoded by default
Displayit's 296. The limit for the DNS record TXT value is 255.I'm a bit ... unusual user, but such users are best to polish the corner cases. Here are explanations of what each address is:
10.x.x.x:41756- my Wifi LAN address, only useful for local connectivity, in /24 network76.x.x.x:41756- my external public IPv4 of my ISP's router100.x.x.x:4175- my tailscale VPN LAN address in /32 network172.x.0.1:41756- some internal docker address, not useful for any connectivity, except between containers172.x.0.1:41756- as above192.168.xxx.x:41756- I actually don't know. It'svirbr0interface, the iface is actually DOWN, probably some virtualization software[200:xxxx:xxx:xxxx:xxx:xxxx:xxxx:xxxx]:41757- my public yggdrasil network I'm testing ipv6 I believe, kind of useful[2603:8001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:41757- my external public IPv4 of my ISP's router[2603:8001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:41757- another one, I thinkBeta Was this translation helpful? Give feedback.
All reactions