4 ms·

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

poizan42 3y ago
IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10
- jve 3y ago
  > IPv10 Which is fine, because it is IPv2 in human readable form after all.
- LinuxBender 3y ago
  We may wish to skip that one as well. [1][2] [1] - https://www.noction.com/blog/ipv10 https://www.noction.com/blog/ipv10 [2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/ https://datatracker.ietf.org/doc/draft-omar-ipv10/10/
  - BizarroLand 3y ago
    OK, so let's just crank it all the way to 11, since 11 is 1 more than 10. I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility. Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.
    - 0cf8612b2e1e 3y ago
      Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local. So 0000:0000 local network, 0000:0001 legacy internet.
      - BizarroLand 3y ago
        Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all? Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities. Actually, now that I've done the math, why not just extend IPv4 into hexadecimal? Once again, none of the current addresses would change with this change, but it would turn 60 billion possible addresses (12^10 = 61,917,364,224) into 184 quadrillion addresses (12^16 = 184,884,258,895,036,416). I feel like that would give us plenty of wiggle room. Sure, it's not on par with ipv6's ability to assign a unique address to every atom on the planet 100 times, but I think it would be enough for the next 40 years or so, right? And it's inherently backwards compatible, what's not to love about it?
        justcool393 3y ago
        > what's not to love about it hexadecimal, unironically. the url of http://[2002:914b1:::1] http://[2002:914b1:::1] is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required. http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 would've at least looked a bit better than it is. would've been super easy too. imagine the convo: "what's google's DNS IP in IPvX?" "oh it's just 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8"
        BizarroLand 3y ago
        So, in my IPv4.1 suggestion, every address you currently know would work perfectly fine. But then so would AE1.224.78.BC2 Sure, a little harder to remember maybe, but adding nearly a billion times as many IP addresses would alleviate the strain on the internet, be backwards compatible with IPv4 (but not forwards compatible, so most interior/home networks would use either a NAT or have a software ipv4-4.1 bridge software) It would also be much more similar to IPv6 which would ease transition to full IPv6 if the human race survives long enough to ever make the jump. IPv6 is just more hexadecimal after all.
  - WorldMaker 3y ago
    IPv12 is twice as good as IPv6, right? Note: This post is a joke and not expected to be a normative RFC and not under any sort of conformance with Internet Drafts under the IETF.
    - LinuxBender 3y ago
      Note: This post is a joke and not expected to be a normative RFC Totally. I only suggested as a means to avoid conflating a real RFC with a joke RFC. And I only did that because half of the things I have joked about resulted in having to say "No, wait, I was kidding, what are you doing?!?" and thus I learned to minimize joking about things.
AtlasBarfed 3y ago
I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet? 2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change. 3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades. So, what's wrong with this? It's obviously naive. Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?
- AtlasBarfed 3y ago
  OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that might not work ... or maybe it will?
  - greyface- 3y ago
    You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.

poizan42 3y ago

IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10

jve 3y ago
> IPv10 Which is fine, because it is IPv2 in human readable form after all.
LinuxBender 3y ago
We may wish to skip that one as well. [1][2] [1] - https://www.noction.com/blog/ipv10 https://www.noction.com/blog/ipv10 [2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/ https://datatracker.ietf.org/doc/draft-omar-ipv10/10/
- BizarroLand 3y ago
  OK, so let's just crank it all the way to 11, since 11 is 1 more than 10. I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility. Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.
  - 0cf8612b2e1e 3y ago
    Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local. So 0000:0000 local network, 0000:0001 legacy internet.
    - BizarroLand 3y ago
      Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all? Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities. Actually, now that I've done the math, why not just extend IPv4 into hexadecimal? Once again, none of the current addresses would change with this change, but it would turn 60 billion possible addresses (12^10 = 61,917,364,224) into 184 quadrillion addresses (12^16 = 184,884,258,895,036,416). I feel like that would give us plenty of wiggle room. Sure, it's not on par with ipv6's ability to assign a unique address to every atom on the planet 100 times, but I think it would be enough for the next 40 years or so, right? And it's inherently backwards compatible, what's not to love about it?
      - justcool393 3y ago
        > what's not to love about it hexadecimal, unironically. the url of http://[2002:914b1:::1] http://[2002:914b1:::1] is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required. http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 would've at least looked a bit better than it is. would've been super easy too. imagine the convo: "what's google's DNS IP in IPvX?" "oh it's just 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8"
        BizarroLand 3y ago
        So, in my IPv4.1 suggestion, every address you currently know would work perfectly fine. But then so would AE1.224.78.BC2 Sure, a little harder to remember maybe, but adding nearly a billion times as many IP addresses would alleviate the strain on the internet, be backwards compatible with IPv4 (but not forwards compatible, so most interior/home networks would use either a NAT or have a software ipv4-4.1 bridge software) It would also be much more similar to IPv6 which would ease transition to full IPv6 if the human race survives long enough to ever make the jump. IPv6 is just more hexadecimal after all.
- WorldMaker 3y ago
  IPv12 is twice as good as IPv6, right? Note: This post is a joke and not expected to be a normative RFC and not under any sort of conformance with Internet Drafts under the IETF.
  - LinuxBender 3y ago
    Note: This post is a joke and not expected to be a normative RFC Totally. I only suggested as a means to avoid conflating a real RFC with a joke RFC. And I only did that because half of the things I have joked about resulted in having to say "No, wait, I was kidding, what are you doing?!?" and thus I learned to minimize joking about things.

AtlasBarfed 3y ago

I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet? 2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change. 3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades. So, what's wrong with this? It's obviously naive. Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?

AtlasBarfed 3y ago
OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that might not work ... or maybe it will?
- greyface- 3y ago
  You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.