I've taken the easier solution of Cloudflare's free Tunnel service so my IP is less exposed and I don't have to poke holes in my firewall.
On principle, I prefer to poke a hole in my firewall than allow surveillance of the plaintext traffic.
141–150 of 183 posts
I've taken the easier solution of Cloudflare's free Tunnel service so my IP is less exposed and I don't have to poke holes in my firewall.
On principle, I prefer to poke a hole in my firewall than allow surveillance of the plaintext traffic.
This and the comments highlight how bad many ISPs in North America and Western Europe are at IPv6, still , in 2025, and the lengths to which people will go to treat that as damage and literally route around it. One of the biggest ISPs in my country has been promising IPv6 since 2016. Another, smaller, competitor, advertised on "World IPv6 Day" in 2011 that it was way ahead of the competition on supplying IPv6; but in…
Once again I voice the only sane option: Skip IPv6 and the insanity that it is, and do IPv8 and simply double (or quadruple) the address space without introducing other new things.
Earlier quoted context omitted.
It'll be objectively worse. IPv6 is at least sort of supported by a non-negligible number of devices, software and organizations. This IPv8 would be a whole new protocol, that no one out there supports. The fact that version 8 was already defined in [an obsolete] RFC1621 doesn't help either. Even if you decide to try to make it a Frankenstein's monster of a protocol, making it a two IPv4 packets wrapped in each other…
Are you saying you believe it's truly impossible to create a new backwards compatible standard that expands the address space and doesn't require everyone to upgrade for it to work?
What kind of IP addresses are these?
Earlier quoted context omitted.
For a long time, I operated from home with a auction-purchased IPv4 /24 just so I could get around all this BS and have my own AS. There's nothing nicer than being able to BGP peer and just handle everything yourself. I really miss old Level 3 (before the Lumen/CenturyLink buyout). Kind of kicking myself for selling my netblock but it was a decent amount of money ($6000).
I'm doing exactly this. I got my netblock for free in 1993, back in the Internic days before ARIN existed. I have a couple of VPSes running BGP and tunnel traffic back to my home over wireguard.
What if I you will your netblock to me? I'll will you my camaro and my collection of amiga parts.
(I really want your netblock)
Earlier quoted context omitted.
Are you saying you believe it's truly impossible to create a new backwards compatible standard that expands the address space and doesn't require everyone to upgrade for it to work?
It isn't possible to make backwards compatible standard that expands the address space. Where are you going to put the extra address bits in the IPv4 header? It also can't be backwards compatible with IPv4 networking and software. The network gear will drop extra address, the OS will ignore it, and software will blow up. It would be much better to make a new version. But if going to make new protocol, might as well m…
> Where are you going to put the extra address bits in the IPv4 header?
The optional part. EIP proposed using 16 bits (minimum) to bump the address space to 40 bits (the EIP extension portion is variable-sized so it can go higher until you reach header option limits): https://archive.org/details/rfc1385/page/4/mode/2upI've taken the easier solution of Cloudflare's free Tunnel service so my IP is less exposed and I don't have to poke holes in my firewall.
Last I checked Cloudflare insisted on terminating TLS on the free tier. On principle, I prefer to poke a hole in my firewall than allow surveillance of the plaintext traffic.
I think in theory you could get it without it but that would be a lot more work on the recipient side.
Me I'm less worried about that so I accept the convenience of not having to setup a reverse proxy and poke a hole in my router.
Earlier quoted context omitted.
It'll be objectively worse. IPv6 is at least sort of supported by a non-negligible number of devices, software and organizations. This IPv8 would be a whole new protocol, that no one out there supports. The fact that version 8 was already defined in [an obsolete] RFC1621 doesn't help either. Even if you decide to try to make it a Frankenstein's monster of a protocol, making it a two IPv4 packets wrapped in each other…
Are you saying you believe it's truly impossible to create a new backwards compatible standard that expands the address space and doesn't require everyone to upgrade for it to work?
There's no straightforward way of getting old hosts to be able to address anything in the new expanded space, or older routers to be able to route to it.
So you have to basically dual-stack it, and, oops, you've created the exact same situation with IPv6...
This and the comments highlight how bad many ISPs in North America and Western Europe are at IPv6, still , in 2025, and the lengths to which people will go to treat that as damage and literally route around it. One of the biggest ISPs in my country has been promising IPv6 since 2016. Another, smaller, competitor, advertised on "World IPv6 Day" in 2011 that it was way ahead of the competition on supplying IPv6; but in…
Once again I voice the only sane option: Skip IPv6 and the insanity that it is, and do IPv8 and simply double (or quadruple) the address space without introducing other new things.
Your IPv8 is what IPv6 should have been. Instead, IPv6 decided to re-invent way too much, and is why we can't have nice things are are stuck with IPv4 and NAT. Just doubling the address width would have given us 90% of the benefit of V6 with far less complexity and would have been adopted much, much, much faster.
I just ported some (BSD) kernel code from V4 to V6. If the address width was just twice as big, and not 4x as big, a lot of the fugly stuff you have to deal with in C would never have happened. A sockaddr could have been expanded by 2 bytes to handle V6. There would not be all these oddball casts between V4/V6, and entirely different IP packet handling routines because of data size differences and differences in stuff like route and mac address lookup.
Another pet peeve of mine from my days working on hardware is IPv6 extension headers. There is no limit in the protocol to how many extension headers a packet can have. This makes verifying ASICS hard, and leads to very poor support for them. I remember when we were implementing them and we had a nice way to do it, we looked at what our competitors did. We found most of them just disabled any advanced features when more than 1 extension header was present.