tjgq

The Javascript coercion rules, arcane as they are, are actually part of the spec and (barring any bugs) should work across browsers.

Is that a distinction worth making? By that standard, how many countries in the world are actually democracies?

> IMNAL, but my understanding is that such a law would run into rock solid, granite hard, iron clad parts of a little issue called the US Constitution. E.g., if the cops ask you a question, then you don't have to answer. The person's lawyer can just tell the cops that "My client has no idea what that base 64 gibberish is."

The US Constitution hasn't helped prevent the PATRIOT act, or the TSA's unreasonable search powers.

> A huge fraction of all Internet data is sent as base 64. So, base 64 data alone is nothing suspicious.

There's a difference between Base64 that decodes into a harmless cat picture, and Base64 that's apparently random. Unless we make it normal for everyone to have encrypted, random-looking data lying around, the few that choose to have it will be increasingly harassed by the government, even if they're not doing anything wrong.

And then they will outlaw the possession of said standard C software, as well as of computer hardware that does not comply with government-mandated eavesdropping. And then they will pass laws that force you to give up the encryption key to that Base64 data or face imprisonment. Even if the Base64 data is just a sequence of completely random bits - because who would keep sequences of random bits around, unless they're a terrorist trying to hide something?

I'm sorry, but I don't think pushing encryption down into the underworld is a viable solution to the problem. There's no limit to the bad laws that the government can pass. The only real long-term solution is to recognize encryption as a right, otherwise we'll only keep seeing these repeated attempts to outlaw it.

It can be even worse than that. A significant number of routers forward IPv4 packets in hardware but fall back to a software implementation for IPv6. So it might happen that the real bottleneck is not memory but throughput.

As for sticking with IPv4 for increased capacity, it depends. Private networks might get away with it for their internal traffic, but no major ISP nowadays will deliberately choose not to route IPv6 for their customers.

Given that worldwide Internet adoption is still growing strong, it is conceivable that sooner or later a significant number of endpoints will only have IPv6 connectivity, or that their IPv4 connectivity will be limited to a private address behind a carrier-grade NAT.

Another point to consider is that there are things you can do with IPv6 connectivity that are very difficult/costly, or outright impossible, in NATted IPv4 land.

Personally, I'm waiting for the next generation of peer-to-peer protocols that make use of end-to-end IPv6 connectivity instead of hole-punching and proxying through third-parties. (Case study: ever thought how ridiculous it is that in 2015 it's still non-trivial to send a large file to someone over the Internet without using some sort of storage service?)

It's plausible that one of those new applications could end up being the "killer app" for IPv6.

In the absence of a firewall, you are correct that any node that gets hold of the publicly routable address assigned to one of your devices will be able to communicate with it from the outside. This is indeed a problem for most users, who won't know or bother to configure one; ISPs should do it for them on the CPE.

Regarding the tracking of specific users: RFC 3041 stateless autoconfiguration (which is deployed at least on Linux and OSX - not sure about Windows) allows a device to switch to a new random IPv6 address within its assigned prefix every few minutes. This mitigates, though it does not eliminate, an attacker's ability to correlate connections originating from the same device over a period of time.

Naturally, all of those addresses will share a common IPv6 prefix. But that is no different from most residential NATs, where all connections are observed from the outside to originate from the same IPv4 address.

Also due to stateless autoconfiguration, guessing the address of a device from the outside is equivalent to finding a needle in a 2^64-straw haystack. It's not impossible, but it takes time and a lot of traffic to do so.

I certainly did not mean to be condescending. I offer my apologies if my post came across as so.

What you want is called a firewall.

There seems to be this common misconception that a firewall and a NAT box are the same thing, but they're not. It just happens that most NAT implementations also work as firewalls (though not the other way round).

Even if you don't have a firewall, the odds of someone discovering your IPv6 address by chance (i.e. without you communicating with them first) are incredibly low. Common IPv6 deployment practice is to delegate at least a /56 prefix to each end user, so your device gets an address chosen at random from 2^72 possibilities. You can even hop into a different address every few minutes for added security (some IPv6 stacks do this).

So please don't spread the misconception that IPv6 is somehow less secure than IPv4! :)

Totally agree with you in that IPv6 and the end of NATs are great for the Internet.

My honest (though possibly unpopular) opinion is that the incentive should have been given years ago through government intervention, by legally compelling ISPs to provide IPv6 connectivity to their customers. If most of the Internet had been switched to IPv6 by now, no bidding war over IPv4 addresses would need to take place.

Naturally, it's moot to point out what could have been done and wasn't. But I think this illustrates a limitation of market-based incentives: they seem to work well on the short term, but have a tendency to fail on the long one. Slow IPv6 adoption is, in my view, a market failure that should have been corrected through government intervention.

> Compared to a world where you can't get IPs at any price? Seems pretty obvious: you can get IPs.

You seem to be presenting a false dichotomy; there are plenty of intermediate solutions between the current state of affairs and a laissez-faire market. At the very least, if we're going to set a price on IPv4 addresses, I think it should be set by the RIRs - not by the companies to whom they were allocated. (Remember that RIRs have the right to reclaim addresses that are not being used.)

In other words: my concern is not that IPv4 addresses end up having a price tag on them; that seems inevitable at this point. My concern is that big players might be able to dictate the prices and effectively buy the small ones out of the Internet.

So in what way exactly does the Internet as a whole benefit from allowing IPv4 addresses to be traded in a free market?

This is a honest question. I would like to know how we avoid ending up in a world where a few large companies control all the available IPv4 addresses (which they don't really need) so they can rent them to the rest of us at exhorbitant prices.

IPv6 won't render the problem moot - it's likely that IPv4 addresses will remain a necessity for globally reachable services for years to come, regardless of IPv6 adoption.

I actually wasn't aware of that! Thanks for the link.

Then anyone would be able to trigger the autodestruct by spoofing their UA.

I'm not sure what the typed array limitations are, but Javascript numbers are able to exactly represent integers up to 2^53 - 1, which is quite a bit more than 32 bits.

Possibly the same reason why the market share of old versions of Internet Explorer is higher on workdays: slower uptake on corporate environments when compared to residential customers.

It declares a variable named r10 and instructs the compiler to store it in the r10 CPU register. It's a GCC extension; the farthest you can get in standards-compliant C is

    register long r10 = a3;

but the register keyword is advisory only (the compiler is free to ignore it) and you cannot specify the exact register you want to be used.

Reference: https://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html

At the end of the video, he does mention that it works for any digit. A more honest way to present the argument would be to start with "let x be any decimal digit..." but I suspect most non-mathematicians wouldn't be able to follow that.

I understand the argument for enterprise networks. Residential customers have everything to gain from using their IPv6 space, and provider-independence isn't an issue for them.

It's worth noting that NPTv6 is a lot better than NAT, though. For one thing, it operates strictly at the IP level and doesn't muck about with the transport layer. So, for instance, if you want to use a transport other than TCP or UDP, it should be possible - at least in principle - even if you are NPTing to and from ULA space. That's something you haven't been effectively able to do on the Internet for the past 20 years.

I think it's a wonderful thing that the TCP/IP model (as originally envisioned) does not preclude endpoints from implementing their own transport protocols on top of IP, irrespective of what the rest of the network uses.

Unfortunately, reality has conspired against this possibility in two ways: NAT boxes, and the fact that transport protocols are implemented in the kernel on most operating systems (hence, an application cannot use its own transport protocol easily).

The deployment of IPv6 is a real chance to, at least, fix the first of these problems. Let's hope it does.

> And NAT doesn't go away with IPv6. That was another belief that did not survive its first encounter with reality.

If it doesn't go away, it will be only because of ISP greed (i.e., charging customers for a larger number of publicly routable addresses). Otherwise, there simply is no reason not to give every customer a /56 or even a /48, given that routers won't be able to route prefixes longer than that anyway.

Fortunately, most ISPs offering native IPv6 so far have turned out not to be that greedy.

> Which assumptions? Using multiple connections is pretty standard in the enterprise storage world.

TCP congestion control is designed such that, under steady-state conditions, each TCP stream traversing a physical link gets an equal share of the available bandwidth. When an application that uses multiple TCP connections competes with another that uses a single one over the same link, the resulting bandwidth distribution is unfair to the latter. (Edit: there's also another problem, related to bufferbloat, but that one is a lot trickier to explain).

Of course, this may not be a problem when used on an internal network (which I assume is the scenario you are referring to). On the public Internet, however, HTTP is becoming increasingly disruptive to other kinds of traffic due to the increasing number of parallel connections used by web browsers.

SCTP would be the ideal solution, but it's essentially broken on the wide Internet since virtually no NAT boxes understand it.

Using a large number of TCP connections breaks some of the assumptions behind TCP congestion control; this is one of the reasons why the SPDY/HTTP2 guys decided to layer a multi-stream protocol on top of a single TCP connection - and it still falls prey to head-of-line blocking.

Not sure what you mean by using an internal work queue - short of running a custom TCP/IP stack in kernel space or using some non-standard socket API, there's no way to work around TCP's ordered delivery.

Given these constraints, I can understand why designing a transport protocol on top of UDP might be reasonable. There probably is no need to roll your own, though - just use SCTP over UDP [1]. (Edit: I only noticed you did mention SCTP/UDP after I wrote my reply, sorry!)

[1] https://tools.ietf.org/html/rfc6951

On the flip side, TCP forces you into a single ordered stream and head-of-line blocking. If you need a reliable yet unordered message stream, you have to reinvent the wheel on top of UDP.

Although I'm not really sympathetic to the OSI model, it did get some things right. For instance, witness how almost every TCP/IP protocol has to roll out its own session layer for authentication purposes...

Hence my inital premise: if memory hadn't gotten so cheap, we would have transitioned into IPv6 already. For all the good Moore's Law brought us, it is also the reason why we seem to be stuck in this NAT world with no end in sight.

Deploying RFC 4193 at least would not pollute the global routing table with lots of short prefixes. Those enterprise networks would pay for that flexibility themselves instead of forcing the cost onto the whole Internet.

If memory wasn't so cheap, we would have transitioned to IPv6 long ago instead of coping with an ever increasing global routing table.

To be fair, it's not entirely the same sort of thing. Git is an open protocol. Github just happens to be one of many sites hosting git repositories. Moving a repository to another host is trivial; you already have all the data in your local tree.

Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperating with other social networks.

Doesn't quantum erasure essentially invalidate the Copenhagen interpretation? (Naive question; I have a relatively shallow understanding of QM, but Copenhagen has always seemed unscientific to me due to the quasi-supernatural role of the observer).