That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.

Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.

The GP poster is correct. Super 8mm film is not "video" and hence is not "home video". NTSC VHS is absolutely 60 fields per second. The only way to get 24 FPS on VHS is with 3:2 pulldown, which no consumer cameras I know of ever did. Even getting close to a "real" simultaneously-sampled 30 frames per second instead of 60 interlaced fields would require a sample-and-hold, which again consumer VHS camcorders didn't have AFAIK.

You should have updated to IPv6, where is no such checksum in TCP.

I think you're misinformed. IPv6 has no IP header checksum, unlike IPv4. However, the higher-level protocol checksums are still there; in fact, UDP over IPv6 is required to include a valid checksum, unlike in IPv4 where it can optionally be 0x0000.

No it's not. Gmail (and most of Google's other high-profile Web stuff) is written with their Closure tools, which is JavaScript-based. Wave was GWT (their Java cross-compiler), but that was about it for public services other than the AdWords admin interface.

Even with a Facebook page, you still have an asininely-short arbitrary limit to the size of status updates that, given the length of Linus's update, doesn't appear to apply to Google+.

As an additional factor, who other than GoDaddy supports both DNSSEC and easy-and-prompt-to-configure IPv6 glue records? I specifically moved from Network Solutions to GoDaddy because it took NetSol weeks to set up my IPv6 glue. (Their interface at the time was "Email us at ipv6req@networksolutions.com and we'll get around to it eventually. Maybe." Maybe they've added it to their admin interface at this point...)

At the IPv4 burn rate of the last month, Ford's space would last only another 10 days. IPv4's done; stick a fork in it and start moving on.

I wonder how they have managed to solved the condensation problem.

They run their oil at 40C. If the dew point in your server room is that high you have other problems...

Couldn't the ISP's DNS return a bogus IPv4 address for somecorp.com and then rewrite packets sent to that address as IPv6 packets to somecorp.com's IPv6 address?

This is called NAT46 and is one of the myriad transition strategies available in both directions. It is much more complicated than NAT64, though, since you need a giant state table synchronized between a router and DNS server, and you need to "waste" some IPv4 space for the mapping, which is in short supply. (NAT64 only needs to keep state in the router, since you can embed the literal v4 address inside a v6 address.)

Or I can forward whatever protocol number to my VPN server. The fact that NAT is possible does not mean that I have to limit yourself to one external IP. If I have two VPN servers I can use two external IPs for them.

IPsec AH headers protect the integrity of the source and destination IP addresses (by design), so if those are modified in any way by NAT things will break.

Anyway, you are clearly okay with NAT's limitations. I am not; I only use it out of necessity. Different strokes...

Breaking trough NAT without port forwarding - sure. The only reason why the protocol might not work with NAT with port forwarding is if it for some reason does not trust the header of the packet and adds a copy of the IP address in the data section (like ftp does).

That's not the only reason. IPsec, for instance, has to be wrapped inside UDP (called IPsec NAT-T) to break through NATs since IPsec was designed to be run directly on top of IP, where there is no concept of ports to forward! Any attempt to go beyond TCP and UDP runs horribly afoul of NATs.

So, I can make a packet destined to 1::2 port 80 (hmm, with IPv4 I can write 1.2.3.4:80, is some other symbol used for marking the port number? 1::2:3:4:80 could be confusing?) actually go to 1::3 port 80?

(To put a literal IPv6 address in a URL you write http://[2001:db8::1]:80/. I suspect other places expecting a colon-separated port number will use a similar scheme.)

Great - it means I can still publish only one IP and do the port mappings, which makes this "almost" NAT.

So, the only thing that cannot be done is rewriting the source IP field on outgoing connections (not packets, since for port forwarding to work it has to work both ways)?

Yes, not unless you use a proxy. Simple inbound port forwarding doesn't need to be implemented as some fancy stack-level kernel feature like NAT; you just need a process listening on a port that, upon accepting, makes a connection to another IP and port and copies the data in both directions. The classic cheesy way to implement this is to throw a line in inetd.conf that calls "nc ip port", though for things like HTTP an application-specific reverse proxy will work a lot better and possibly take some of the load off of your web server(s) if it caches.

It's likely a fair amount of NAT-like behavior will be written for IPv6 to support implementing transparent proxies, which do have to happen at the stack level. I just want the amount of NATted traffic on the Internet at large to be on the opposite end of the bell curve than it is now, since with IPv6 it will be unnecessary to "share an Internet connection" in the same way as IPv4.

The point is, I do not want NAT to be imposed on everyone. I just want the option of doing whatever I want to the packets that enter and leave my network, including changing the address fields, for whatever reason. If something does not work for me because of NAT that I myself placed there, so be it, I'll find a workaround or, if it really bugs me, stop using NAT.

...

There is no reason not to have NAT as an option.

If this were the only side-effect, than sure. But a lot of protocols in use today (peer-to-peer filesharing, VOIP, VPN, etc.) have had horrible kludges built into them to ensure that they can break through NAT and still work. NAT is also a huge barrier to entry to interesting new transport layer protocols like SCTP, since it absolutely requires specialized code in the NAT router.

If you want to NAT IPv6 for no particularly good reason, and the world breaks for you, that's fine, but if anybody has to waste time abusing perfectly good future protocols to work with IPv6 NAT the damage is much more substantial than you. And if the myth that NAT provides a useful service persists, the market will demand such hacks.

As I said in reply to another post, i might want to make example.com:80 and example.com:21 connect to different physical (or virtual) servers. Without modifying DNS and doing the whole www.example.com and ftp.example.com thing.

So make your router (or other box) explicitly do port forwarding and/or load-balancing; it's effectively what you're using NAT for here and would likely be more flexible.

Embedding IPv4 within the IPv6 address space and allowing for a smooth transition was another option. As a society, we have chosen not to take that option. We have chosen uncertainty, confusion, and NAT instead.

No, it wasn't; at least not without NAT (or otherwise modifying IPv4).

You can indeed embed IPv4 inside the IPv6 address space, and various techniques do that today (the ::ffff:0.0.0.0/96 socket API bridge and various NAT64 schemes being two obvious examples). But when an IPv4-only host receives a packet, it only receives 32 bits of source address. Something in the middle that is aware of IPv6 would need to keep some state to be able to reply to the full 128-bit IPv6 address. That's NAT64, and it exists. But it's definitely NAT.

A tin-bearing copper alloy (brass, idiots!)

Funny. But for future rants, copper-tin alloys are bronze. Brass is copper-zinc.

It's not even "spoofing" to pick a random IPv6 address, it's a standard:

RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Windows does this by default.