Hacker News Reader

Comment by roblabla | Hacker News Reader

I'm pondering on this. I think the idea is to allow ipv6-only users to connect to ipv4-only users -- thus making the IPv6 migration "easier" for, e.g., ISPs that are deploying ipv6-only networks (especially on mobile). But the RFC doesn't really mention that anywhere.

I might be missing something though.

View on HN

The ipv4-only users still need a way to specify an ipv6 address to talk to ipv6-only users. This RFC seems to suggest that they should just send an ipv10 packet. But then they wouldn't be ipv4-only anymore, and might as well adopt ipv6.

I think the idea here is to have to update the end points only, not having to upgrade the expensive infrastructure in between, which was the reason IPv6 was so slow to be adopted in the first place.

The expensive infrastructure needs to be taught about ipv10, unless it doesn't actually look at the packets. Maybe there are some that ignore the protocol version field and could be tricked into treating it like an ipv4 packet, but there's nothing in the RFC to suggest that's the plan.

I don't think that's possible. The routers are the ones that need to decode the IPv10 packet, see if it contains an IPv4 or IPv6 destination and route accordingly. From my reading of the RFC that means all routers, not just the customer appliances. It kinda feels like IPv6 all over again.

> That means, if the received IPv10 packet contains an IPv4 address in the destination address field, the router should use the IPv4 routing table to make a routing decision, and if the received IPv10 packet contains an IPv6 address in the destination address field, the router should use the IPv6 routing table to make a routing decision.

Most consumer routers don't really maintain routing tables (aside form some static mappings for you internal network) so this appears targetted at actual internet/ISP routers.

<sarcasm> Those big expensive things that we regularly replace and provide with updates. </sarcasm>

Decoding internet packets at scale is usually done inside hardware so at the very least we'll need new ASICs for this I'm guessing.

> [..] and the IPv10 deployment process can be accomplished by ALL technology companies developing OSs for hosts networking and security devices. [..]

Sometime further down the line this shows up though:

> [..] and it is just a software development process in the NIC cards of all hosts to allow encapsulating both IPv4 and IPv6 in the same IP packet header. [..]

I'm not quite sure what the author is getting at but packet encapsulation isn't cheap, you usually don't want to do that in software for large routers, unless they're outfitted with FPGAs for this purpose and you reprogram those instead. I've also never actually seen a firmware update for my NIC show up so I wonder how they envision that happening. Even if that's the case, you'd then still need to update all hosts, which to me seems far from trivial.

Problem was mandatory multicast support for IPv6 for the last decades, which requires a lot of memory upgrades to the routers, which nobody cares, because they rather invest in other things than memory upgrades to their routers. Why should they support better TV and Youtube streaming might be their reasoning.

Where did you get this information from? Core internet routers do not really get "memory upgrades" at all (like it's a stick of ram you can replace, it's not), especially for multicast routing requirements.

Yes, that's why nobody's doing it.

I have the same understanding here. It allows those who switch to IPv6 easily communicate with IPv4 (backward compatibility?)...a bit confusing though since this is handled at router level.

We had a strange case recently...some of our remote staff were unable to connect to our NY VPN from SC. After tracing we found their ISP started using IPV6. Anyways, after we made changes...within a few hours the isp went back to IPv4.

Edit - 19 years to switch is a long time...old as the modern internet. Don't fix it if it ain't broken :)

Besides, we've already got a solution to maintain IPv4 connectivity from IPv6-only networks anyway, DNS64 and NAT64. There's literally an entire /96 subnet in the IPv6 address space dedicated to this task, 64:ff9b::/96.

Reply on news.ycombinator.com