5 ms·

That was always a question I had in the back of my mind. We have this huge address space. Why not reserve a single prefix that means "look at the lower 32-bit

That was always a question I had in the back of my mind. We have this huge address space. Why not reserve a single prefix that means "look at the lower 32-bits of this address and use it as an IPv4 address"?

karlshea 13y ago
There are, there's a prefix that maps to IPv4 addresses.
jewel 13y ago
This can be done by the ISP with a combination of DNS64 and NAT64.
1c4050b09 13y ago
So sort of exactly like 64:ff9b::/96 in NAT64?
vklj 13y ago
Every IPv4 packet needs a source address. If the client is IPv6, what is the IPv4 source address? You would want to assign an IPv4 address to the client transparently; and, since they're scarce, share it with several clients. That's what NAT64 does.
- mSparks 13y ago
  Why not just have the first 32 bits of ipv6 as equivelent to ipv4 so the ipv6 address of 66.249.73.108 is 66.249.73.108:0
  - welterde 13y ago
    What does that gain you over the mapped suffix, where you embed the IPv4 address at the end? (which is used by NAT64, etc.)
    - mSparks 13y ago
      because as I understand routing is still done from the MSB. So you leave the IPv4 existing infrastructure in place with no modification, but all those /32 addresses now become useful and all the existing IPv4 infrastructure and routing paths still work. Rather than having to replace every single piece of hardware, software, nameserver and routing stack that works on IPv4. I could plug my IPv6 router into any ISP that gives a v4 address and have as many v6 addresses as could ever be needed. It makes no sense to me why you would route IPv4 addresses on v6 LSB, it completely ignores current internet infrastructure and routing.
      - welterde 13y ago
        What you propose already exists and is called Teredo,6rd or other tunneling protocols (6to4/6rd is probably the best fit with getting a /48 per IPv4 address). Except they again map the IPv4 space into the suffix of the IPv6 address (or do no mapping depending on the protocol). But you don't want to do that forever as you are now paying for a IPv4 header PLUS some more headers instead of just one IPv6 header if you have native IPv6.
        mSparks 13y ago
        No, I'm not talking about tunneling, I'm saying natively route at the v4 level, and the header will be less, because +160bit addresses will only be used when required. so your routing table holds "66/4 port 1" ,"* port 2" instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?). My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already. As it is, we are all still using workarounds (and VPNs).
        welterde 13y ago
        > No, I'm not talking about tunneling, I'm saying natively route at the v4 level, and the header will be less, because 128bit addresses will only be used when required. There are multiple issues with this. The first and probably most important one is that it doesn't address routing table fragmentation, which is pretty much solved with IPv6, because most ISPs will end up announcing on the order of 1 or 2 prefixes instead of dozens, which can't ever be aggregated (like is the case in the IPv4 world right now and will only get worse). The second one is, that it doesn't gain you much in terms of deployment over IPv6 + tunnels. > so your routing table holds "66/4 port 1" ,"* port 2" > instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?). Ok.. I have no idea what you are talking about here (mainly your notation is leaving me confused).. > My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already. Even in the presence of NAT?
giovannibajo1 13y ago
That covers ipv6 hosts sending a packet to ipv4 hosts. How do you propose they answer though? They can't put a ipv6 address in the ipv4 header. The full solution is NAT64.

karlshea 13y ago

There are, there's a prefix that maps to IPv4 addresses.

jewel 13y ago

This can be done by the ISP with a combination of DNS64 and NAT64.

1c4050b09 13y ago

So sort of exactly like 64:ff9b::/96 in NAT64?

vklj 13y ago

Every IPv4 packet needs a source address. If the client is IPv6, what is the IPv4 source address? You would want to assign an IPv4 address to the client transparently; and, since they're scarce, share it with several clients. That's what NAT64 does.

mSparks 13y ago
Why not just have the first 32 bits of ipv6 as equivelent to ipv4 so the ipv6 address of 66.249.73.108 is 66.249.73.108:0
- welterde 13y ago
  What does that gain you over the mapped suffix, where you embed the IPv4 address at the end? (which is used by NAT64, etc.)
  - mSparks 13y ago
    because as I understand routing is still done from the MSB. So you leave the IPv4 existing infrastructure in place with no modification, but all those /32 addresses now become useful and all the existing IPv4 infrastructure and routing paths still work. Rather than having to replace every single piece of hardware, software, nameserver and routing stack that works on IPv4. I could plug my IPv6 router into any ISP that gives a v4 address and have as many v6 addresses as could ever be needed. It makes no sense to me why you would route IPv4 addresses on v6 LSB, it completely ignores current internet infrastructure and routing.
    - welterde 13y ago
      What you propose already exists and is called Teredo,6rd or other tunneling protocols (6to4/6rd is probably the best fit with getting a /48 per IPv4 address). Except they again map the IPv4 space into the suffix of the IPv6 address (or do no mapping depending on the protocol). But you don't want to do that forever as you are now paying for a IPv4 header PLUS some more headers instead of just one IPv6 header if you have native IPv6.
      - mSparks 13y ago
        No, I'm not talking about tunneling, I'm saying natively route at the v4 level, and the header will be less, because +160bit addresses will only be used when required. so your routing table holds "66/4 port 1" ,"* port 2" instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?). My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already. As it is, we are all still using workarounds (and VPNs).
        welterde 13y ago
        > No, I'm not talking about tunneling, I'm saying natively route at the v4 level, and the header will be less, because 128bit addresses will only be used when required. There are multiple issues with this. The first and probably most important one is that it doesn't address routing table fragmentation, which is pretty much solved with IPv6, because most ISPs will end up announcing on the order of 1 or 2 prefixes instead of dozens, which can't ever be aggregated (like is the case in the IPv4 world right now and will only get worse). The second one is, that it doesn't gain you much in terms of deployment over IPv6 + tunnels. > so your routing table holds "66/4 port 1" ,"* port 2" > instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?). Ok.. I have no idea what you are talking about here (mainly your notation is leaving me confused).. > My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already. Even in the presence of NAT?

giovannibajo1 13y ago

That covers ipv6 hosts sending a packet to ipv4 hosts. How do you propose they answer though? They can't put a ipv6 address in the ipv4 header. The full solution is NAT64.