With a telegram you have a telegraph operator who types up your message for you then sends it. With a postcard you have a sorter / deliverer who reads the address and sees the message even if it is not read. Neither process is fully automated.

With email you type up your own message and send it into a system that does not require human interaction to deliver the message. The only time a human other than the intended recipient sees a email is when there is a delivery error.

"Lift the buckle" is not the same as "push the button". Airplane seat belts have different mechanisms to most (not all) car seat belts and while you may use a car seat belt 600+ times a year, unless you are a frequent flyer you don't come anywhere close to that in a plane even going to the toilets. The message is telling the passengers that there is a different mechanism in the hope that it will save your life in the event of a survivable crash.

Which is basically down to lack of experience rather than actual gaps in protocol coverage.

Most ISP's are only now starting to ask "how do I do this". They should have been asking this question 7 to 8 years, if not longer, ago.

Actually it is utilisation. IPv4 ran out of addresses over a decade ago when NAT no longer became optional for the majority of users of the Internet. Ever since then we have been in stopgap mode. Unfortunately most users have never experience the real Internet when everyone can be both a producer and a consumer.

In most of the world you can use cryptography for authentication even if you can't use it for confidentiality.

Without cryptographically verified authentication you can't even verify the MX or A records are valid so you have nothing to verify against. It is only a matter of time, if they are not already, spoofing DNS responses to enable delivery of their messages.

It's perfectly possible to authenticate email with distributed senders. It just requires willingness to deploy the tools to do it. This includes updated clients. Whether that email is spam or not is a orthogonal matter.

MX records are for inbound traffic. SPF is for outbound traffic. Don't mix the two.

SPF is not a spam solution. Spammers can have legitimate SPF records.

SPF is design so that the recipient can reject forged emails without the blow back impacting the person whose email address is being forged. This only works if the published SPF records reflect reality.

Google could deliver IPTV and cut into the TV market as well. TV is digital these days. The analog cable plants are almost all gone.

DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.

DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetected. With DNSSEC the worst they can do is reduce the effective number of name servers for the zone.

As for OpenDNS you still have to establish a trusted path to them.

Neither does DNSCurve.

Which is not a problem of DNSSEC per say but a basic problem of DNS. It is also solvable. It just requires will to deploy the solutions.

This was a explicit non goal of DNSSEC.

No more than DNS leaks private data.

Eyeball ISP's that light up IPv6 and control the router see a significant percentage of traffic (double digits) as IPv6.

Content sites that enable IPv6 see ~1% of traffic being IPv6.

ISP's that delay turning on IPv6 are just increasing their long term costs as they will need to install bigger CGN's and will have a bigger customer base to move when the time comes as customers will continue to buy IPv4 only equipment.

For most sites there is not a significant cost or pain to deploy IPv6 these days. The servers boxes already support IPv6 as do the desktops.

For a home user, assuming that their ISP supports IPv6, you are looking at replacing a single router. IPv6 capable routers can be got for around $150
and cheaper ones are coming.

For customer facing servers you turn on IPv6 in the router or check the IPv6 box with the cloud provider. Add a test DNS entry with the IPv6 address for the server and check that your backends work. Once that is done you put a AAAA address on the main DNS entry. If thing break at this sage you remove the AAAA record and re-test.

The day to day costs of dual stack vs IPv4 only is negligible.

add pass tcp from any to me 22 setup in keep-state

It might not be iptable but it is a firewall rule.

Virgin Media are missing the point. Some places in the world have already run out of IPv4 address and Virgin Media have customers that need to talk to those places. There is no good IPv4 to IPv6 solution.

Additionally delaying deploying IPv6 just forces their customers to delay testing of IPv6 with their systems. ISP are already years behind where they should be and this is just Virgin Media using spin merchants to deflect from the fact that they dropped the ball.

Firstly NAT64 isn't tunnelling, it is translation. Secondly NAT64 does NOT work for IPv4 initiated connections. As long as you have legacy IPv4 only devices that need to talk to the world you need a IPv4 path out bound. This could be dual stack, DS-Lite, 4rd.