7 ms·

IPv4, don't get me wrong, I like much more than IPv6 for many reasons(128 bits? Overkill). There are more people on Earth than ipv4 addresses, you can't solve

by axaxs 8y ago

IPv4, don't get me wrong, I like much more than IPv6 for many reasons(128 bits? Overkill). There are more people on Earth than ipv4 addresses, you can't solve that problem without heavy NATing, which has its own drawbacks.

exabrial 8y ago
I think you missed my point, so I'll explain another way because I think it's important to make. If you look at the TCP packet, bits 16-31 are constant for all HTTP traffic. Because they are a fixed value, they're wasted (non-unique). With the current system, we can only have 2,147,483,647 web servers. Using SRV records, these bits become distinguishable, giving us 281,474,976,710,656 possible addresses for web servers. [Yes this is an oversimplification for the pedantic]
- icedchai 8y ago
  The Host: header has allowed multiple web servers at the same public IP address for ages. Now, all you need is a reverse proxy...
- axaxs 8y ago
  I'm not sure I get your point clearly, even now. Are you stating dst port could be used for other things? I'm honestly unclear how 'static' bits in TCP relate to IPv4.
  - haldean 8y ago
    I think they're saying that most things that go over TCP are HTTP, which means usually those bits are set to 80 or 443. With SRV records we could be using more ports, and then presumably do port based routing instead of host based routing on the back end.
  - spatular 8y ago
    Idea is to treat (ip, port) pair as single 6-byte endpoint address. Each endpoint would be able to run just one service (well, two, one for tcp, another for udp). Type of service would be determined by looking up PTR record. On the downside you won't be able to easily tell if two services run on a same machine or not. SSH and HTTP endpoints would be related only through DNS. I think doing it in compatible way that doesn't require replacing routers would require NATs on both sides, and client that looks up PTR records before connecting.
    - axaxs 8y ago
      Ah. That is actually an interesting idea I had never thought of. That said, it has its drawbacks as well - especially when it comes to who owns what. IPv4 are mainly all gone. So even if we tack two bytes onto each address, I'd assume those who got the allocations would get those additional addresses.
bluejekyll 8y ago
I disagree that 128 bits is overkill. Most networks are devided between 64bits for public routing, and 64bits for internal routing. The network space is huge, but segmented. At each branch of the network, you reduce your addressable space significantly. When you think of the future, and huge interconnected small devices, I don’t think 128 bits are going to seem excessive. Remember, when they came up with 32bits for IPv4, they were not planning for a computer (or multiple!) in your pocket that was going to be network routable.
- JdeBP 8y ago
  Because the minisec that Arthur C. Clarke had postulated in Imperial Earth in 1975 and the commlock that appeared in Space:1999 also in 1975 were both obviously fantastic nonsense. (-: One can see from IEN28 in 1978 that early forms of 32-bit addressing, at the time comprising 1 octet network, 1 octet IMP, and 2 octets host, weren't even planned as extending beyond ARPANET.
- axaxs 8y ago
  To play devil's advocate, there are not enough raw materials on earth to produce close to the amount of necessary devices that would fill the ipv6 space. I can be convinced that this large amount has other benefits, but not that this number of IPs was needed for futureproofing.
  - UncleEntity 8y ago
    Well...https://xkcd.com/865/ https://xkcd.com/865/
  - jchw 8y ago
    Well, there's a couple other considerations. For one thing, some devices may have multiple IPv6 addresses - perhaps even entire slices of it. For another, having additional bits to work with allows people more room to divide their subnets into future-proof chunks without risking ever running out of IPv6 space - something IPv4 could never really afford in the first place. What would be considered large chunks of IPv4 are a drop in the bucket in IPv6. I think the main idea is that you want to have plenty of space both for growing horizontally and vertically, at least enough to where you can't even imagine exhausting it in either direction. Giving massive private and public address space without need for NATs effectively provides this. Also, hey, who knows. There isn't enough raw materials on Earth, perhaps, but maybe there are enough raw materials in the universe. Who knows for sure if the Internet always be confined to just Earth.
lokedhs 8y ago
Are there? 2^32 is roughly 4 billion. There are almost twice as many people on earth.
- falsedan 8y ago
  > There are more people on Earth than ipv4 addresses Assuming you're responding to this? That statement is unwieldy but clear (would have preferred there aren't even enough IP addrs to uniquely identify every currently living person or some such).
  - lokedhs 8y ago
    Yes I was, and I was misreading the original comment.

by axaxs 8y ago

exabrial 8y ago

I think you missed my point, so I'll explain another way because I think it's important to make. If you look at the TCP packet, bits 16-31 are constant for all HTTP traffic. Because they are a fixed value, they're wasted (non-unique). With the current system, we can only have 2,147,483,647 web servers. Using SRV records, these bits become distinguishable, giving us 281,474,976,710,656 possible addresses for web servers. [Yes this is an oversimplification for the pedantic]

icedchai 8y ago
The Host: header has allowed multiple web servers at the same public IP address for ages. Now, all you need is a reverse proxy...
axaxs 8y ago
I'm not sure I get your point clearly, even now. Are you stating dst port could be used for other things? I'm honestly unclear how 'static' bits in TCP relate to IPv4.
- haldean 8y ago
  I think they're saying that most things that go over TCP are HTTP, which means usually those bits are set to 80 or 443. With SRV records we could be using more ports, and then presumably do port based routing instead of host based routing on the back end.
- spatular 8y ago
  Idea is to treat (ip, port) pair as single 6-byte endpoint address. Each endpoint would be able to run just one service (well, two, one for tcp, another for udp). Type of service would be determined by looking up PTR record. On the downside you won't be able to easily tell if two services run on a same machine or not. SSH and HTTP endpoints would be related only through DNS. I think doing it in compatible way that doesn't require replacing routers would require NATs on both sides, and client that looks up PTR records before connecting.
  - axaxs 8y ago
    Ah. That is actually an interesting idea I had never thought of. That said, it has its drawbacks as well - especially when it comes to who owns what. IPv4 are mainly all gone. So even if we tack two bytes onto each address, I'd assume those who got the allocations would get those additional addresses.

bluejekyll 8y ago

I disagree that 128 bits is overkill. Most networks are devided between 64bits for public routing, and 64bits for internal routing. The network space is huge, but segmented. At each branch of the network, you reduce your addressable space significantly. When you think of the future, and huge interconnected small devices, I don’t think 128 bits are going to seem excessive. Remember, when they came up with 32bits for IPv4, they were not planning for a computer (or multiple!) in your pocket that was going to be network routable.

JdeBP 8y ago
Because the minisec that Arthur C. Clarke had postulated in Imperial Earth in 1975 and the commlock that appeared in Space:1999 also in 1975 were both obviously fantastic nonsense. (-: One can see from IEN28 in 1978 that early forms of 32-bit addressing, at the time comprising 1 octet network, 1 octet IMP, and 2 octets host, weren't even planned as extending beyond ARPANET.
axaxs 8y ago
To play devil's advocate, there are not enough raw materials on earth to produce close to the amount of necessary devices that would fill the ipv6 space. I can be convinced that this large amount has other benefits, but not that this number of IPs was needed for futureproofing.
- UncleEntity 8y ago
  Well...https://xkcd.com/865/ https://xkcd.com/865/
- jchw 8y ago
  Well, there's a couple other considerations. For one thing, some devices may have multiple IPv6 addresses - perhaps even entire slices of it. For another, having additional bits to work with allows people more room to divide their subnets into future-proof chunks without risking ever running out of IPv6 space - something IPv4 could never really afford in the first place. What would be considered large chunks of IPv4 are a drop in the bucket in IPv6. I think the main idea is that you want to have plenty of space both for growing horizontally and vertically, at least enough to where you can't even imagine exhausting it in either direction. Giving massive private and public address space without need for NATs effectively provides this. Also, hey, who knows. There isn't enough raw materials on Earth, perhaps, but maybe there are enough raw materials in the universe. Who knows for sure if the Internet always be confined to just Earth.

lokedhs 8y ago

Are there? 2^32 is roughly 4 billion. There are almost twice as many people on earth.

falsedan 8y ago
> There are more people on Earth than ipv4 addresses Assuming you're responding to this? That statement is unwieldy but clear (would have preferred there aren't even enough IP addrs to uniquely identify every currently living person or some such).
- lokedhs 8y ago
  Yes I was, and I was misreading the original comment.