hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

8.9K
active users

#ipv4

2 posts2 participants0 posts today
Replied in thread

@torproject Q: I wish there was a similar tool test #Bridges, as bridges.torproject.org/scan/ is not that good and I don't want to hammer it with dozens of addresses, cuz at best that's quite antisocial if not possibly trigger responses assuming this is an intelligence gathering operation.

  • Ideally sone standalone binary that one can just give a list of #TorBridge|s in a text file (similar to the way one can just past them in at #TorBrowser) would help.

I.e.

bridgetest -v4 obfs4 203.0.113.0:80 …

bridgetest -v6 webtunnel [2001:DB8::1]:443 …

bridgetest -list ./tor.bridges.list.private.tsv
  • But maybe #onionprobe already does that. In that case please tell me to "#RTFM!"

Similarly there needs to be a more granular way to request #TorBridges from #BridgeDB (as it's basically impossible to get #IPv4 #Webtunnel addresses nor is there an option to filter for #ports like :80 & :443 to deal with restrictive #firewalls (i.e. on public #WiFi)…

  • there are flags like ipv6=yes but neither ipv4=yes nor ipv6=no yielded me other resultd than #IPv6 webtunnel bridges…

And before anyone asks: Yes, I do have a "legitimate purpose" as some of my contacts do need Bridges to get beyond a mandatory firewall and/or do use #TorBrowser (through an #SSH tunnel) to circumvent Tor & #VPN blocks and maintain privacy (as many companies do block sometimes entire #Hosters' ASNs due to rampant #scrapers

bridges.torproject.orgThe Tor Project | Privacy & Freedom OnlineDefend yourself against tracking and surveillance. Circumvent censorship.
Replied in thread

@Jarek @landley that assumes #IPv6 addresses are static (Providers in #Germany do "pseudostatic" alike #IPv4 and unless one's a business customer, will forcibly disconnect once each 24 hours and reassign a new IP) and that applications ain't configured to prefer IPv4 over IPv6 just to avoid timeouts and having to check if IPv6 exists since the only "#IPv6only" #ISP I know is #Starlink (and even they do #CGNAT due to customer complaints…)

Replied in thread

@landley @jschauma @ryanc @0xabad1dea yeah, the exhaustion problem would've been shoved back with a #64bit or sufficiently delayed by a 40bit number.

Unless we also hate #NAT and expect every device to have a unique static #IP (which is a #privacy nightmare at best that "#PrivacyExtensions" barely fixed.)

  • I mean they could've also gone the #DECnet approach and use the #EUI48 / #MAC-Address (or #EUI64) as static addressing system, but that would've made #vendors and not #ISPs the powerful forces of allocation. (Similar to how technically the #ICCID dictates #GSM / #4G / #5G access and not the #IMEI unless places like Australia ban imported devices.

I guess using a #128bit address space was inspired by #ZFS doing the same before, as the folks who designed both wanted to design a solution that clearly will outlive them (way harder than COBOL has outlived Grace Hopper)...

If I was @BNetzA I would've mandated #DualStack and banned #CGNAT (or at least the use of CGNAT in #RFC1918 address spaces) as well as #DualStackLite!

Continued thread

@tails_live @tails @torproject plus support for meek, snowflake, webtunnel and non-#obfs4 #Bridges seems missing in #Tails.

Cuz to this day I've to yet see an IPv4-#webtunnel #bridge

bridges.torproject.orgThe Tor Project | Privacy & Freedom OnlineDefend yourself against tracking and surveillance. Circumvent censorship.
#meek#snowflake#Tor

Just wanted to share some thoughts on #RFC9715 - an #RFC that defines standards on reducing the #DNS issue of IP fragmentation over #UDP. It's not a long read, but a good one for everyone who understands the issues of large UDP responses on the #Internet. A great leap forward to (hopefully) reduce the reflection/amplification #DDoS potential of DNS.

Just today I learned that #Google will configure their public DNS resolvers to limit to ~1400 bytes (smaller adjustments expected while figuring out the sweet spot in production). From now on, DNS responses which exceed this limit will have the truncated flag set instructing the client to resolve back to #TCP.