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
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
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!
In fact, that would be dangerous too in a roller coaster. You should keep you arms inside the carriage... But a ban on bringing your own arms around on the ride could be a little difficult to enforce. People tend to be quite attached to their arms.
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.