It's still very much an issue, since even NAT is running this, and we need to get into 2 layers of NAT, such as NAT 444. That sort of networking won't be much different from SPX/IPX networking that we once had from Novell, where the communications were layer 2 rather than layer 3. IPv6 by contrast enables pure layer 3 communications

Problem is if you tried to redefine everything within the 127. space that's not 127.0.0.1 as public unicast space, you'd have to fiddle w/ the IPv4 protocol of every router, and then you'd have 2 versions of IPv4 in supposedly IPv4 compatible equipment. That would pretty much end IPv4 communications as we know it. Even today, there is IPv4 equipment that's unaware of CIDR or subnet masks or even NAT.

You are right about the wastage, but you're forgetting something: IPv4 was never designed for global use. It was designed by the DoD purely for use by the Pentagon and everybody they worked w/. They were never going to get anywhere even close to 4 billion users, and given the scope of what they were, it was the right fit. Now IPv4 went viral, became a part of TCP/IP and caught on, and once the scope became the whole world, it was woefully inadequate for the job. The IETF recognized that, and set on working on a successor. Since any new protocol would have broken compatibility, since the address header would no longer be 32 bits, they made the new protocol address header 128 bits, so that it was unlikely to be ever changed. Of course, that meant breaking compatibility w/ every piece of Layer 3 equipment, which is why they went for the clean room approach. Some of the concepts they tried to lock in - such as autoconfiguration - was IMO overkill, and ended up potentially restricting this protocol as well, but I think that we could in future get to a point where we could use /96 subnets instead of /64.

But they can inter-operate. There are so many transport mechanisms for them - Dual Stack, Dual Stack-Lite, Teredo, CGNAT, et al.

Compatibility is an irrelevant term here: the correct concept would be 'inter-operable'. It's like the comparison b/w a freeway and a surface street. I could get from Santa Clara to San Mateo via El Camino Real, or I could get there via the I-280. It would be stupid to suggest that I-280 should have been built right next to El Camino Real so that people would use the former in preference to the latter. Or that I-280 gets less traffic b'cos it's not compatible w/ El Camino Real. Truth is that some cars could use the freeway, while those not familiar w/ the I-280 could continue to use ECR. People who use the latter would be those who don't know how to take the 280 from Santa Clara to get to the 92 exit.

It looks like the issue here is that since IPv6 addresses are freely assigned to any node in a network devoid of DHCPv6, nodes that shouldn't belong in that network get IP addresses, and thereby access to all traffic within the network. In IPv4, if DHCPv4 weren't there, a node has to be manually configured, or else, it doesn't get an address. In IPv6, if DHCPv6 ain't there, a node still gets an address courtesy the combination of SLAAC, ND and DAD.

The solution to this would be to mandate DHCPv6, but networks that choose to avoid it allow the free assignment of addresses to any node within the range of the network, such as tablets or phones that see the SSID. Routers see that thing within the network, and assume that it needs to be assigned one of the addresses from their range. If that node happens to be a hostile spying node, it gets the access and then automatic entry into the VPN, thereby defeating its purpose. With DHCP, one could define which nodes get IP addresses and which don't.

If this is the model that any VPN service uses, it's really stupid, for 2 reasons:

• - It combines the weakness of IPv4 tunnels i.e. overlapping private address ranges, and the weakness of IPv6 gateways - proactively assigning node addresses if DHCPv6 ain't supported
• - It ignores one of the greatest strengths of IPv6 - better connectivity for VPNs

In IPv6, there would be 3 ways to natively support a VPN:

• - Use Unique Local Addresses (fd00::/8) which would ensure a good likelihood of non-overlapping address ranges
• - Make a VLAN of Global Unicast Addresses from the 2 networks in question, adding only the nodes that need to be in it
• - Assign addresses from one of the networks to nodes in the other, and set up a proxy connection b/w the two

Simply extending IPv4 concepts to IPv6 is likely to break things, given the changes in how the networks are built: in IPv4, nodes have to request addresses, whereas in IPv6, nodes are automatically assigned addresses. So when constructing VPNs, network admins would have to account for those differences while defining their networks.

Frankly, I don't see how a VPN could be constructed if the IPv6 networks in question don't have DHCPv6 support. That's the minimum that needs to be there, otherwise every node in the networks would be a part of a VPN, regardless of whether they need to be or not. A few days ago, we were discussing DHCPv6 support in Android: this is one of the cases where SLAAC + DAD/ND is inadequate, and where you need to have a well defined address assignment policy

This. Preferably the FreeBSD License, since it's the same license that's used by the FreeBSD parts of iOS

Your mom, your wife, your baby and you. Makes it 4, of which one of you can't take photos.

You can fit several thousand photos in a 4GB stick. It would be useful for taking not just stills, but videos of the customers as well, while they're on the rides.

Well, to be fair, when we go on vacations, it is useful to have photos of ourselves along w/ those surroundings. Otherwise, any video of that place that's publicly available would have been adequate, and people wouldn't bother taking cameras w/ them. Having ourselves in those pics is a part of what creates the memories. Also, while those pictures are mostly of value to them, they are really shared w/ friends and family. What makes it look like it's being shared w/ the 'public' is that too many people are all too happy to add a gazillion people as their friends on FaceBook

But I do agree w/ you about the selfie sticks.

If there are 4 of you, then there is no reason that one of you can't take a photo of the other 3, and for the all of you photo, call a bystander. This is if y'all are outdoors, maybe touring some place. If you are indoors, it's not all that difficult to set up the timer mode on the camera, and in 10 seconds, get the shot of all of you.

The only people for whom they're really useful is a single person, or a single person and his/her kid, w/ the kid too young to take a pic. But even then, using the timer mode, or holding it at arms length makes it easy, particularly since you can see how you look before clicking!

Fully agree! I had gone for years missing taking pics of myself. But recently, when I had my kid over for vacation and was taking him around, I asked someone to take our pics. Aside from that, in the mall, I managed to take a reasonably good picture of both of us just holding the phone at arms length.

It wouldn't be dangerous per se: it would only make it more likely that the person drops the phone, and depending on the height, end up breaking or otherwise damaging it. Although on the rides, paying attention to the photos as opposed to the rides is more dangerous. If you have someone in your party who's not on the ride, have him/her take the photo from the ground - or preferably, a video, so that he doesn't have to struggle w/ the correct positioning wrt you.

Problem is that these photographers are still stuck in the 20th century, and will give you a printout. They may sell you a CD if you pay more. That's my biggest turn-off: I don't keep photo albums any more, and don't want a folder cover for a slaughtered tree photo. I have my tablets, laptops, phones, and can even get an electronic photoframe if I wish where I can store any number of photos w/o taking up more space.

I don't mind paying for the ride photo services if they take electronic photos and then deliver it to us in a way of our choosing - either email, WhatsApp, iMessage or any other medium of our choosing, not theirs.

But DHCPv6 would only assign the addresses for 1 or more subnets within the network. Like if the admin has a 2001:db8:bead::/60, DHCP would manage the 16 subnets within that network. But if there was a tablet on that network that also accessed 2001:db8:d0g:a1e:/64, the DHCP wouldn't touch the addresses that that tablet got from this other network. That tablet would have to be separately administered and configured, and if it is set up to accept connections to other networks, there it is. Granted, it's another security issue, but one very separate from the question of whether a device should only be allowed 1 or more IP addresses.

There are a lot of reasons why a network admin might want control on his address mapping scheme, that has nothing to do w/ either probability (irrelevant here, since DAD eliminates the possibility of duplicate addresses) nor the convenience of auto-configuration or an 'understanding of IPv6'.