4 ms·

> "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IMO ipv6 would have gotten far more adoption had t

by est31 6y ago

> "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IMO ipv6 would have gotten far more adoption had they used a different assignment scheme: * Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142 * New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly. In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today. Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now. Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.

welterde 6y ago
Then you are missing the chance to simplify things though. In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network. Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough? In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP. Compare this to the IPv4 case where each ISP will have hundreds of /24s. Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.
- est31 6y ago
  Indeed the routing tables can be simplified with ipv6. However I believe that the current solution is optimized too much for routing tables, and not at all for end-user usability. You can modify my proposal to have multiple 16-bit prefixes to the 32-bit range syntax, and from that /80 range you give ASs depending on size a /104, /96, or /88, or something in between. That would still leave plenty of room for the ASs to distribute addresses to customers. Maybe customers could get /8s or such, with the option for bigger customers to get larger assignments. NAT on the router could be enabled by default, reserving the range for devices which explicitly request a publicly reachable address. Usually in most networks that number should be small.
  - miyuru 6y ago
    End users do not need easier IP address unless they host something. even then one can use address compressed address and DNS. The thing with IPv6 is it very different than IPv4, as such how we use it should not be compared with IPv4. My ISP gives /64 for CPE and the internal routing is very easily setuped. My devices in the hotspot has different IPv6 address, VMs have different IP address. The communication between the devices happen locally without any NAT.
Dagger2 6y ago
Every IPv4 address has its own IPv6 /48 automatically assigned to it. Forget getting more adoption, apparently it wasn't even enough to stop people from suggesting that v6 should've done something it already did!
- est31 6y ago
  Yes there are multiple ways that ipv4 can be translated into the ipv6 range. That's not what I'm suggesting here. I'm suggesting the existing ipv4 assignments to natively work in ipv6.
  - Dagger2 6y ago
    And we have that, don't we? Every assigned v4 address comes with a v6 /48 too. There's no translation involved with that.
    - est31 6y ago
      What I indicated in my comment above is that I dont know which of the many existing ways to embed the v4 range into the v6 address space you are talking about. Can you please tell me so that we can discuss it? Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.
      - Dagger2 6y ago
        I'm thinking of 6to4.
  - PowerBar 6y ago
    That would only work, at best, in 1 direction. If Alice has IPv6 and Bob has IPv4, Alice can send Bob a packet to either 1.2.3.4 or ::01:02:03:04, but if Alice's IPv6 number isn't in the IPv4 range (ex: ::10:11:12:13:14), then her IPv6 number won't have a corresponding IPv4 number that she can put in the IPv4 IP header (because the IPv4 header only allocates enough bytes to exactly fit 1 IPv4 header in the from field and 1 IPv4 header in the to field). This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.
lopmotr 6y ago
What happens when future people want to use other addresses outside those rules? Tons of software will have been written only ever seeing the limited address range and will have bugs for more general addresses. Some programmers might even forget that other addresses are possible and intentionally limit what their software can handle. It could become a defacto smaller address space, making the rest of the address as complete waste forever.
- est31 6y ago
  That's a good point. Indeed, in a vacuum world it would be very much a problem that needs to be addressed. Right now however, there are ipv6 addresses in use that use the other end of the spectrum already. During the migration period it won't be a problem either. In the far future, where most traffic uses the new scheme, one can hand out temporary ranges from the traditional ipv6 assignments to high-traffic ASs. And even if you don't do such measures, the rest of the address space won't be a "complete waste forever", one will just have to identify the implementations which have problems with these addresses and change them. It's a solvable technical task like any other.
  - lopmotr 6y ago
    Sure, if there are already address at the other end like there are by now. > one will just have to identify the implementations which have problems with these addresses and change them Isn't that what converting from IPv4 to IPv6 is? It's really hard.

by est31 6y ago

welterde 6y ago

Then you are missing the chance to simplify things though. In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network. Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough? In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP. Compare this to the IPv4 case where each ISP will have hundreds of /24s. Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.

est31 6y ago
Indeed the routing tables can be simplified with ipv6. However I believe that the current solution is optimized too much for routing tables, and not at all for end-user usability. You can modify my proposal to have multiple 16-bit prefixes to the 32-bit range syntax, and from that /80 range you give ASs depending on size a /104, /96, or /88, or something in between. That would still leave plenty of room for the ASs to distribute addresses to customers. Maybe customers could get /8s or such, with the option for bigger customers to get larger assignments. NAT on the router could be enabled by default, reserving the range for devices which explicitly request a publicly reachable address. Usually in most networks that number should be small.
- miyuru 6y ago
  End users do not need easier IP address unless they host something. even then one can use address compressed address and DNS. The thing with IPv6 is it very different than IPv4, as such how we use it should not be compared with IPv4. My ISP gives /64 for CPE and the internal routing is very easily setuped. My devices in the hotspot has different IPv6 address, VMs have different IP address. The communication between the devices happen locally without any NAT.

Dagger2 6y ago

Every IPv4 address has its own IPv6 /48 automatically assigned to it. Forget getting more adoption, apparently it wasn't even enough to stop people from suggesting that v6 should've done something it already did!

est31 6y ago
Yes there are multiple ways that ipv4 can be translated into the ipv6 range. That's not what I'm suggesting here. I'm suggesting the existing ipv4 assignments to natively work in ipv6.
- Dagger2 6y ago
  And we have that, don't we? Every assigned v4 address comes with a v6 /48 too. There's no translation involved with that.
  - est31 6y ago
    What I indicated in my comment above is that I dont know which of the many existing ways to embed the v4 range into the v6 address space you are talking about. Can you please tell me so that we can discuss it? Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.
    - Dagger2 6y ago
      I'm thinking of 6to4.
- PowerBar 6y ago
  That would only work, at best, in 1 direction. If Alice has IPv6 and Bob has IPv4, Alice can send Bob a packet to either 1.2.3.4 or ::01:02:03:04, but if Alice's IPv6 number isn't in the IPv4 range (ex: ::10:11:12:13:14), then her IPv6 number won't have a corresponding IPv4 number that she can put in the IPv4 IP header (because the IPv4 header only allocates enough bytes to exactly fit 1 IPv4 header in the from field and 1 IPv4 header in the to field). This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.

lopmotr 6y ago

What happens when future people want to use other addresses outside those rules? Tons of software will have been written only ever seeing the limited address range and will have bugs for more general addresses. Some programmers might even forget that other addresses are possible and intentionally limit what their software can handle. It could become a defacto smaller address space, making the rest of the address as complete waste forever.

est31 6y ago
That's a good point. Indeed, in a vacuum world it would be very much a problem that needs to be addressed. Right now however, there are ipv6 addresses in use that use the other end of the spectrum already. During the migration period it won't be a problem either. In the far future, where most traffic uses the new scheme, one can hand out temporary ranges from the traditional ipv6 assignments to high-traffic ASs. And even if you don't do such measures, the rest of the address space won't be a "complete waste forever", one will just have to identify the implementations which have problems with these addresses and change them. It's a solvable technical task like any other.
- lopmotr 6y ago
  Sure, if there are already address at the other end like there are by now. > one will just have to identify the implementations which have problems with these addresses and change them Isn't that what converting from IPv4 to IPv6 is? It's really hard.