This is not how the Internet's DNS "root servers" work.

On IPv6 replacing IPv4

This could be interesting to watch. In the early days of IPv6 that I was tracking, it seemed like there were many new features built into it that made the protocol better than IPv4. Perhaps those competitive features were abandoned. In a footnote to this article, the authors state:

The original proposals for IPv6 included several novel services, such as mobility, improved auto-configuration and IP-layer security, but eventually IPv6 became mostly an IPv4-like protocol with many more addresses.

In order to be adopted, IPv6 had to be IPv4 with more address space (mostly to fulfill the needs of the mobile computing marketplace). But to simplify itself so that mobile carriers could easily understand and adopt it, does the feature parity with IPv4 mean that IPv4 never goes away?

Defining the "EvoArch" (Evolutionary Architecture) hour-glass model

The hour-glass model is the way it is because these middle core protocols profile a stable foundation experimentation and advancement in upper and lower level protocols. That also makes these middle protocols harder to change, as we have seen with the slow adoption of IPv6.

How to enable IPv6 for Docker

agreed that this Road could use more Paving. the lone, stressed out operator might not be the ideal circumstance for such paving.

great feature, already discussed in Prefix Delegation how powerful it can be, what a win for security & privacy it is.

this feature enables things like the super cool ipv6 privacy extensions in Linux, where connections get random ip addresses. i think Apple has a similar offering? rather than have all activity come from a single IP address, that activity can now look like it comes from across a subnet of addresses. this also allows service isolation, such that your file-sharing protocol is the only thing offered on one ip address, your dns service is the only thing available on another ip address, &c. this is really powerful, privacy protecting, giving computers multiple ip addresses. ipv6!

accurate. that is what firewalls are for? what is bad or the downside about that? it's not computationally complex, home routers should be able to offer this network security you want.

the amount of networking hell we have had to endure because devices are not on the internet has been vast. i know we still have some way to go before we can trust in device security, but this warm blanket of network security, of running our own private networks & NAT'ing between, is a malpractice & problematic beyond belief & we need to get better, advance.

there is some salvageable wisdom here. devices should come with an option to run in site-local address scopes, such that they are not routeable. my hope is most devices can be online, but perhaps we can allow for the option to not.

you can easily route any range of addresses, by port, to wherever you want with ipv6. this isn't pure network prefix translation, but that's not the only tool in the shed for ipv6.

where-in the author argues that devices should be kept off the internet & should not have their own internet addresses. which, is, well, conventional & safe, yes. but i tire of this stalemate. i very much would like devices to be connectable.

yes you need dual rules. alas, the legacy world haunts us.

i am all here for explicit behavior over invisible, slow, dangerous behavior. everything written in this section sounds like an escape from a nightmare.

well, almost everything. i scanned the PMTU doc. it looks like the sender has to send large packets in order to trigger the Packet Too Big (PTB) messages, which is un-ideal. it'd be great to ICMPv6 probe this with small packets? bah.

also there is an (expired) "IPv6 Packet Truncation" draft that i'm not sure if is implemented or no (probably not), where a router can truncate the packet & issue the ICMPv6 Packet Too Big back to the sender, such that the IPv6 source can, in some cases, application protocol specific, send the remaining "fragmented" data without loss, at the expected MTU size. notably, this may mean multiple PTB messages if the packet runs into multiple mtu decreases as it goes, creating odd timing & reconstruction issues for those seeking to implement this.

i grow tired of the author bellyaching about big addresses being hard. the switch from . separated to colon separated at least has some grounds for head scratching, but the complaints about long addresses, about long rDNS? please. it's not the prettiest, yes. but it doesn't strike me as bad, or a nightmare. there's critiques on ipv6, but this aint it. this is small.

i can definitely see wanting massive local address space in ipv6. i imagine, for example, creating an untrusted/semi-trusted container/workload that shouldn't know where it's connections are coming from, where all packets are forwarded to it mapped through link local addresses. having this huge address space would allow not just that one container to have this kind of blindfolded addressing happen, but would allow tens of thousands of containers to have this kind of blindfolded addressing work on a machine.

this seems like a weird bone to pick, and it strikes me as a huge feature, offering some very valid flexibility

There's no DHCP server involved with handing out IPv6 addresses.