Dagger2

That's because the problems he's describing come from v4 rather than v6, and v4 hasn't changed in a long time.

Uh, no it didn't? Routing table size is still something of a problem, especially as v4 continues to fragment more and more, but also the main driver was insufficient IP addresses in v4 and that problem hasn't even slightly gone away.

You're at the very beginning, baby steps stage of inventing IPv6 there.

You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does.

Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.

Well, other than the transition plans that it has and still has. The exact same plans that the other options like TUBA had.

If you ignore those then sure, it didn't have a plan.

Try it and see!

  192.168.1.1$ ip link set sit0 up
  192.168.1.2$ ip link set sit0 up
  192.168.1.2$ ping ::192.168.1.1
  64 bytes from ::192.168.1.1: icmp_seq=1 ttl=64 time=0.812 ms

(It works over the Internet too, though make sure your firewall doesn't block protocol 41 and that the packet doesn't get NATed.)

Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.

We don't.

If you're not familiar with IETF drafts, this should give you an idea of the amount of vetting and community support is necessary to get something published as one: https://www.ietf.org/archive/id/draft-meow-mrrp-00.html

But only if you don't hide everybody away behind routers that require HTTP and a host header.

Meanwhile, everybody else is using a plastic skull that they carry around with them to pre-chew the inedible food, which is the majority of the food you can get these days.

"It's not inedible," they say. "Just let me get my skull out."

> IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.

People said the same sort of thing about v4: that it was hard to configure because you needed to know four separate addresses (IP, netmask, default route AND the DNS server) and if you mix up any of these it doesn't work.

As it turns out, in both cases it's just a lack of familiarity, not actual difficulty. The super complex jaw movement is just a regular bite, but you puff your cheeks out a bit. Or er, something.

> This lead to Cisco, Microsoft, and Google all taking completely different approaches [...] but this time they forgot to add a way to communicate a default route

"There should only be one way to do things... wait, no, not like that."

I'm not sure if I'm misreading you, but a /48 would never be an entire country's v6 allocation.

If we're talking home networks, you can reliably expect a /48 to a) not be announced in BGP itself, and b) cover one to a few hundred users of one ISP. (The containing /32 or similar will be announced.) A business might structure its network so that one of its /48s corresponds to a country, but in that case the /48 would be covering just that business, which would be a sensible unit for reputation tracking.

I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.

> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual

That's not really how routes work. Or DNS.

I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.

Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.

German ISPs commonly seem to have an option of their "old" platform (v4 only, no v6) or their "new" one (v6 and CGNATed v4). Maybe you're on their old one? Or maybe they only use it for certain account tiers or somesuch.

Remember that, at one stage, the only two types that were useful were FTP and telnet. HTTP and SSH didn't even exist.

Let's not strangle the next big thing that doesn't exist yet before it can even be born, yeah?

So... how many records and zones? I'm pretty sure I could convey it if I could work out what you were talking about.

You went from "you can't even comprehend or convey the massive number of records and zones that are involved" to one v4 /24, managed "at scale" but by an ordinary consumer, who you expect to be capable of programming. This is a bit all over the place.

It's not any harder to deal with v6 reverse DNS than it is v4. In fact, making every reverse label 4 bits instead of 8, combined with v6 being much bigger than v4, makes rDNS much easier to deal with in v6 because you can generally delegate reverse zones on exactly the same boundaries that you delegate the corresponding IP blocks. In v4, you often need to delegate on boundaries that aren't /8, /16 and /24 and it suddenly gets more annoying.

Scaling up for rDNS is no different to scaling up for forward DNS. It's a well-understood problem.

Copying and pasting was just my attempt to demonstrate how simple a v6 rDNS record is to add. If you were interested in hiring me to write a solution for your ISP, that's fine, but you can't seriously expect random people to do it for you for free in a HN comment.

It should be pretty obvious that a script can generate these records from the forward records or from any other source of IPs/hosts, with no per-address effort needed on the part of the network admins.

How so? The same working group published e.g. https://www.rfc-editor.org/rfc/rfc1933, and it's hard to see how v6 could have been designed for backwards compatibility in ways that it wasn't already.

I've asked lots of people to describe a more backwards-compatible design, and generally the best they can manage is to copy the way v6 does things, ending up with the same problems v6 has. This has happened so often that the only reasonable conclusion is that it can't really be done any better than it was.

So you'll never have a permanent unchanging v6 address to ID your traffic with.

Privacy extensions are orthogonal here; they only affect the suffix, not the prefix. As for dealing with a changing prefix... I'm afraid you'll just have to find some way to automate the DNS updates. You can do it with a program running on one of the servers -- I can't suggest a specific one offhand since I have a static prefix and haven't needed it, but they do exist.

They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.

Many mobile ISPs handle v4 via NAT64 or CGNAT. Routers capable of doing those are far more expensive than regular routers, so there tends to be fewer of them. v4 traffic has to travel out of its way to reach one of those routers, whereas v6 traffic can be handed off sooner with a more direct physical path.

It affects anything where latency matters, e.g. from Facebook: "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." (https://engineering.fb.com/2015/09/14/networking-traffic/ipv...).

Questions like this suggest that 1&1 do: https://forum.openwrt.org/t/solved-dsl-over-ds-lite-with-isp...

I'm less sure about Telekom. For obvious reasons, it's hard to find info in English.

There is -- you can see the weekday/weekend difference is smaller when people are working from home en masse.

  ::203.0.113.42 (tunnels to 203.0.113.42 over v4)
  64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)
  ::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6 socket)

What are these then?

  $ dig -x 2606:7100:1:67::26 | grep PTR
  ;6.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.6.0.0.1.0.0.0.0.0.1.7.6.0.6.2.ip6.arpa. IN PTR

Run this, then copy/paste the output into your zone file. Remove the ; and add "example.com." or whatever to the end.

I agree it's a pain to read, mostly because DNS addresses are written backwards, but an "absurd non-solution"? For a set of instructions that don't even depend on the format of the record (they work for v4 too), and which I could describe in one line in a HN comment?

If this is the craziest part of v6 then it must be incredibly well designed overall.

If you think v6 isn't backwards compatible then literally anything bigger than 32 bits will never count as backwards compatible for you. The whole point of making the address space bigger is to make it bigger, so what do you expect to achieve by complaining that the result is incompatible?

As a human, I've found that e.g. "fd00::53" is perfectly readable to me, and most of the time you're interacting with strings like "news.ycombinator.com" anyway which is identical to how it works in v4, so I'm not sure how far I'd agree with that part either.

You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.

It's very common. German ISPs collectively went with DS-Lite, so most of that 77% with v6 have CGNATed v4.

None of which are any help when connecting to someone who doesn't have those.

Has it been abysmally slow? What's the par time for migrating millions of independent networks, managed by as many independent uncoordinated administrators, to a new layer 3 protocol?

We've never done this before at this scale. Maybe this is just how long it takes?

The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5.

The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)

Privacy extensions are additional addresses that are used by default for outbound connections. You still have the non-privacy address, which doesn't change; put that one into DNS.

This approach prevents outbound connections from leaking the address needed to connect to your servers. On v4, it's likely that any outbound connection from your network gives the server the IP they need to do that.