Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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).


> 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?


the routing table is the same as now, just that the IPv4 address becomes the network which sub routes. IPv4 hardware doesn't need to care about sub routing.

my point is with that notation, right now we have say a google address of 66.249.73.108

How does IPv6 handle retaining all the existing work and man hours that has gone in to making packets go to the 66.249.73/24 network, as quickly as possible, from anywhere in the world.

It seems to me it expects every administrator from top to bottom to start from scratch, then everyone is scratching their heads as to why that hasn't happened.

>Even in the presence of NAT?

No, and this is a good thing, only IPv6 devices which have their own IPv4 address/network can issue IPv6 addresses on that network. This is a good thing. e.g. I get 66.249.73 to be 421D:4900:0:0 in hex.

In what universe does this need to be ditched and started from scratch, and making something:something:0042:1D49 re doing - by hand - every NS, routing table etc

Where did these hundreds of millions of higher level routing tables suddenly come from?

It keep being phrased as "what is the source address of an IPv6 host on an IPv4 network". It seems to me the answer should simply be "the first 32 bits of the IPv6 address" - and it seems stupid it's not structured like this.


> No, and this is a good thing, only IPv6 devices which have their own IPv4 address/network can issue IPv6 addresses on that network.

So you will still need tunneling to make it work. As you will still have to run CGN to get all your customers online. Unless of course you do want to change the network infrastructure. At which point your solution gets much worse than plain and simple IPv6.

> It keep being phrased as "what is the source address of an IPv6 host on an IPv4 network". It seems to me the answer should simply be "the first 32 bits of the IPv6 address" - and it seems stupid it's not structured like this.

Sure.. that solves the routing problem (except for IPv4 routing table explosion), but doesn't solve the problem that IPv4-only hosts still can't talk to IPv5-hosts. You send [IPv4][IPv5] packet to IPv4 host. Huh? What's that IPv5 thing? Or the other way around.. IPv4 host sees AAA record (with IPv5) in DNS..

Your proposal solves nothing that can't also be done with IPv6 and tunnels if you are really keen on keeping your 5 old router running a few more months before throwing it away (which you can't do anyway, as your limited FIB size will force you to buy new hardware anyway, due to IPv4 route table fragmentation).




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: