4 ms·

> I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is

> I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is too much for me. And exactly how would you accomplish this switch to a larger address space? Please explain the steps exactly how they would be done. Because IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How exactly do you fit in >32b in a data structure that is only 32b? You cannot. So you have to go and replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.

CountSessine 4y ago
In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine. There’s no useful and backward compatible way of extending IPv4.
- theamk 4y ago
  Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem. I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
  - wbl 4y ago
    That mistake was already baked in to the sockaddr_t ABI.
    - p_l 4y ago
      BSD Sockets were one giant mistake of not enough abstraction and leaky implementation internals like that.
  - GoblinSlayer 4y ago
    On Windows firewall matches ip4 and ip6 with the same rule. The address field there isn't numeric, but text, and can be ip4 address, ip4 network, ip6 address, ip6 network, address range, gateway or "any". Most rules specify "any" for addresses and focus more on ports, application paths and subprotocols like TCP/UDP.
- AnIdiotOnTheNet 4y ago
  Couple things: 1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets. 2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.
  - anyfoo 4y ago
    Devices with no clue of IPv6 also just drop those packets. What have we gained? The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.
  - Dagger2 4y ago
    Even better, instead of using a reserved unrouted address, use the "IP version" header field, which literally exists for this exact purpose. I'm struggling to see how this would improve anything over what v6 did though.
  - deleted 4y ago
    [deleted]
theamk 4y ago
OK: Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface. Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in4plus" and AF_INET->AF_INET4PLUS. That's it -- since backward compatibility guaranteed, my software still works on IPv4 system, and hostname parsing is not broken. There might be some minor breakage (unexpected dependencies on struct size or ipv4+ address string length), but it would be way, way smaller than the mess IPv6 is in too. Right now, I have to set up my firewall twice for ipv4 and ipv6. But with ipv4+? I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both. Right now, all the network monitoring tools have to have separate "ipv4" and "ipv6" codepaths. But with ipv4+, there could be only one codepath. Yes, packet parsing will have to handle two different IP header format, but once it's parsed, old and new are treated identically. Sure, the network layer will be more complex. The IP stack in kernel would need to determine if the address is "short" or "long", and format packets differently (either old or new format). The high-performance routers would need to be rewritten. The TCP/IP network card offload will need to accommodate new format. But this would be way, way less intrusive than current IPv4->IPv6 transitions, because for each line of low-level network code there are millions of lines of application-level code, and for some totally stupid reason the app code transition was made way harder than needed.
- anyfoo 4y ago
  I am not sure why you are downvoted, since you do make some valid points. I myself am not sure whether the very fundamental changes that IPv6 brings did not hamper its adoption than if it was just extended IPv4. From a network administration perspective, sure, "you need to replace every piece of equipment". But from a software modification perspective (thinking more about the software on network infrastructure equipment than endpoints like applications), you have two very different stacks. On the other hand, if there was ever a time to make (assumedly so) highly desirable compatibility-breaking changes, that was it.
- throw0101c 4y ago
  > I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both. Kind of like how PF does it? tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" block all pass out proto tcp to any port $tcp_services keep state pass proto udp to any port $udp_services keep state * https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tutorial https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tut... If an address family ("af") is not specified, the rule applies to both: […] pf-rule = action [ ( "in" | "out" ) ] [ "log" [ "(" logopts ")"] ] [ "quick" ] [ "on" ifspec ] [ route ] [ af ] [ protospec ] hosts [ filteropt-list ] […] af = "inet" | "inet6" […] * https://www.freebsd.org/cgi/man.cgi?query=pf.conf https://www.freebsd.org/cgi/man.cgi?query=pf.conf action [direction] [log] [quick] [on interface] [af] [proto protocol] [from src_addr [port src_port]] [to dst_addr [port dst_port]] [flags tcp_flags] [state] * https://www.openbsd.org/faq/pf/filter.html#syntax https://www.openbsd.org/faq/pf/filter.html#syntax Perhaps the protocol isn't the problem and you're just using firewall software that doesn't have very good syntax?
Spooky23 4y ago
You just need to do what the world did - NAT. IPv6 is more than just address space extension. There’s all sorts of stuff packed in there that complicates the process. All mobile clients are behind CG-NAT. We should have built standards around that instead of worrying about extending IP space to Mars or whatever.
- throw0101c 4y ago
  > All mobile clients are behind CG-NAT. Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites: * https://www.youtube.com/watch?v=d6oBCYHzrTA https://www.youtube.com/watch?v=d6oBCYHzrTA * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers: * https://www.statista.com/statistics/219577/total-customers-of-t-mobile-usa-by-quarter/ https://www.statista.com/statistics/219577/total-customers-o... One-third of the US population is connecting via IPv6-only on a day-to-day, hour-to-hour basis every time their smartphone reaches out over the radio.
  - School-Cotton 4y ago
    I also have IPv6 on Verizon Wireless. (I don’t know the details of how it connects to IPv4-only hosts.)
  - worthless-trash 4y ago
    Even my smalltime telco in Australia uses ipv6.
    - midoridensha 4y ago
      My fiber-based residential ISP here in Japan uses IPv6, and from what I can tell, they're all like that here.
  - bert64 4y ago
    A lot of mobile telcos use IPv6, but there are virtually no telcos around the world that don't force the use of some form of NAT (CGNAT, NAT64) for connecting to legacy sites. NAT64 is effectively another form of CGNAT, you only have a proper end to end connection if you're using IPv6 directly. TMO US has 110 million customers, but they don't have 110 million legacy IP addresses, and most other telcos are in the same boat.
chillfox 4y ago
There's a huge difference in the effort required of maintainers (both actual work and cognitive) from just upping the integer size vs what IPv6 is.
AtlasBarfed 4y ago
It's like no protocol has ever been extended or revised. Ever. Let's pretend there isn't an Options and Padding section in the IP header: "Options and Padding - A field that varies in length from 0 to a multiple of 32-bits. If the option values are not a multiple of 32-bits, 0s are added or padded to ensure this field contains a multiple of 32 bits." Wow, like I CANNOT think of how that would be used to add more bits. More 32 bit sections? No use for that for ipv4+ or ++ or +++.
- 6510 4y ago
  Lets call the ip4 the area code and serve the Rick Astley video if no further bits are provided.
- Dagger2 4y ago
  There is in fact an options section in v4, and I think it's pretty obvious how it could be used: you could put extra address bits there. The problem is... how do you get those extra address bits to work? If you think through that question and produce a working answer, your working answer is going to be roughly the same as v6 -- and have the same issues v6 does. Almost as if the people that designed v6 weren't completely clueless.

CountSessine 4y ago

In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine. There’s no useful and backward compatible way of extending IPv4.

theamk 4y ago
Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem. I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
- wbl 4y ago
  That mistake was already baked in to the sockaddr_t ABI.
  - p_l 4y ago
    BSD Sockets were one giant mistake of not enough abstraction and leaky implementation internals like that.
- GoblinSlayer 4y ago
  On Windows firewall matches ip4 and ip6 with the same rule. The address field there isn't numeric, but text, and can be ip4 address, ip4 network, ip6 address, ip6 network, address range, gateway or "any". Most rules specify "any" for addresses and focus more on ports, application paths and subprotocols like TCP/UDP.
AnIdiotOnTheNet 4y ago
Couple things: 1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets. 2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.
- anyfoo 4y ago
  Devices with no clue of IPv6 also just drop those packets. What have we gained? The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.
- Dagger2 4y ago
  Even better, instead of using a reserved unrouted address, use the "IP version" header field, which literally exists for this exact purpose. I'm struggling to see how this would improve anything over what v6 did though.
- deleted 4y ago
  [deleted]

theamk 4y ago

OK: Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface. Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in4plus" and AF_INET->AF_INET4PLUS. That's it -- since backward compatibility guaranteed, my software still works on IPv4 system, and hostname parsing is not broken. There might be some minor breakage (unexpected dependencies on struct size or ipv4+ address string length), but it would be way, way smaller than the mess IPv6 is in too. Right now, I have to set up my firewall twice for ipv4 and ipv6. But with ipv4+? I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both. Right now, all the network monitoring tools have to have separate "ipv4" and "ipv6" codepaths. But with ipv4+, there could be only one codepath. Yes, packet parsing will have to handle two different IP header format, but once it's parsed, old and new are treated identically. Sure, the network layer will be more complex. The IP stack in kernel would need to determine if the address is "short" or "long", and format packets differently (either old or new format). The high-performance routers would need to be rewritten. The TCP/IP network card offload will need to accommodate new format. But this would be way, way less intrusive than current IPv4->IPv6 transitions, because for each line of low-level network code there are millions of lines of application-level code, and for some totally stupid reason the app code transition was made way harder than needed.

anyfoo 4y ago
I am not sure why you are downvoted, since you do make some valid points. I myself am not sure whether the very fundamental changes that IPv6 brings did not hamper its adoption than if it was just extended IPv4. From a network administration perspective, sure, "you need to replace every piece of equipment". But from a software modification perspective (thinking more about the software on network infrastructure equipment than endpoints like applications), you have two very different stacks. On the other hand, if there was ever a time to make (assumedly so) highly desirable compatibility-breaking changes, that was it.
throw0101c 4y ago
> I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both. Kind of like how PF does it? tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" block all pass out proto tcp to any port $tcp_services keep state pass proto udp to any port $udp_services keep state * https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tutorial https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tut... If an address family ("af") is not specified, the rule applies to both: […] pf-rule = action [ ( "in" | "out" ) ] [ "log" [ "(" logopts ")"] ] [ "quick" ] [ "on" ifspec ] [ route ] [ af ] [ protospec ] hosts [ filteropt-list ] […] af = "inet" | "inet6" […] * https://www.freebsd.org/cgi/man.cgi?query=pf.conf https://www.freebsd.org/cgi/man.cgi?query=pf.conf action [direction] [log] [quick] [on interface] [af] [proto protocol] [from src_addr [port src_port]] [to dst_addr [port dst_port]] [flags tcp_flags] [state] * https://www.openbsd.org/faq/pf/filter.html#syntax https://www.openbsd.org/faq/pf/filter.html#syntax Perhaps the protocol isn't the problem and you're just using firewall software that doesn't have very good syntax?

Spooky23 4y ago

You just need to do what the world did - NAT. IPv6 is more than just address space extension. There’s all sorts of stuff packed in there that complicates the process. All mobile clients are behind CG-NAT. We should have built standards around that instead of worrying about extending IP space to Mars or whatever.

throw0101c 4y ago
> All mobile clients are behind CG-NAT. Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites: * https://www.youtube.com/watch?v=d6oBCYHzrTA https://www.youtube.com/watch?v=d6oBCYHzrTA * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers: * https://www.statista.com/statistics/219577/total-customers-of-t-mobile-usa-by-quarter/ https://www.statista.com/statistics/219577/total-customers-o... One-third of the US population is connecting via IPv6-only on a day-to-day, hour-to-hour basis every time their smartphone reaches out over the radio.
- School-Cotton 4y ago
  I also have IPv6 on Verizon Wireless. (I don’t know the details of how it connects to IPv4-only hosts.)
- worthless-trash 4y ago
  Even my smalltime telco in Australia uses ipv6.
  - midoridensha 4y ago
    My fiber-based residential ISP here in Japan uses IPv6, and from what I can tell, they're all like that here.
- bert64 4y ago
  A lot of mobile telcos use IPv6, but there are virtually no telcos around the world that don't force the use of some form of NAT (CGNAT, NAT64) for connecting to legacy sites. NAT64 is effectively another form of CGNAT, you only have a proper end to end connection if you're using IPv6 directly. TMO US has 110 million customers, but they don't have 110 million legacy IP addresses, and most other telcos are in the same boat.

chillfox 4y ago

There's a huge difference in the effort required of maintainers (both actual work and cognitive) from just upping the integer size vs what IPv6 is.

AtlasBarfed 4y ago

It's like no protocol has ever been extended or revised. Ever. Let's pretend there isn't an Options and Padding section in the IP header: "Options and Padding - A field that varies in length from 0 to a multiple of 32-bits. If the option values are not a multiple of 32-bits, 0s are added or padded to ensure this field contains a multiple of 32 bits." Wow, like I CANNOT think of how that would be used to add more bits. More 32 bit sections? No use for that for ipv4+ or ++ or +++.

6510 4y ago
Lets call the ip4 the area code and serve the Rick Astley video if no further bits are provided.
Dagger2 4y ago
There is in fact an options section in v4, and I think it's pretty obvious how it could be used: you could put extra address bits there. The problem is... how do you get those extra address bits to work? If you think through that question and produce a working answer, your working answer is going to be roughly the same as v6 -- and have the same issues v6 does. Almost as if the people that designed v6 weren't completely clueless.