First, to those people who make the declaration "Don't be so paranoid, they can take your fingerprints from a door handle or a cup", I retort that you should then have no problem complying with a requirement from an employer/bank/whatever to take your DNA and keep it on file, because obviously they could just get it form a piece of hair or skin you leave around everywhere(welcome to Gattica!). That argument is a batch of crap. The taking of fingerprints is absolutely an invasion of privacy for those who are concerned about malice or undesired use/supeona of the information. And the people making the argument that a hash or encoding of the fingerprint data makes it impossible to use as evidence doesn't understand that law enforcement, etc. can fairly easily obtain that hash, then get a second scan from you and compare the hashes in order to positively identify you.

All that being said, most fingerprint scanners used for timeclocks, door locks, etc. don't store the data with sufficient precision to use it as credible evidence that the scan was you. This is part of why they are both non-trivial and pretty easy to fake. It's precisely that dual, semi-contradictory nature of fingerprint scanners that make them so useful as a biometric access device.

Of course, you have no idea if the biometric scanners used by this university have that kind of precision, so it's probably best for both you and the university if they simply modify the policy to state that the precision of data the devices gather do not and shall not be able to qualify as proof of identity of in a court of law.

Then you're clear. Your biometric data at that point has the same significance as an ID badge. Any use of that data as evidence must be corroborated.

It might not have been such a good idea to contact a paper or other news outlet unless the university refused to clarify their agreement.

I read your journal, and you're essentially talking about is NAT-PT, or a derivation therein. However, there are a couple of essential problems with those solutions:

1. Any protocol that imbeds IP address information into the upper-layer protocol will fail unless that mapping was previously created by the gateway.

2. The solution requires that all communication be through DNS. If the legacy device has an app which doesn't do DNS, how can it reach the endpoint? It can't without a manual mapping in the gateway. And what if the endpoint on the other side is also behind such a gateway? How do I figure out what IPv6 address to map it to?

Essentially, the IPv6 transition problem in it's current state was born because there are 2 primary issues when changing a lower-level protocol like IP:

1. How do endpoints contact each other?
2. How does the routing system get the packets to the endpoints?

IMHO These 2 problems are antithetical to each other. Making a backwards compatible solution to the endpoint problem was causing considerible trouble for those trying to route packets. You have to remember that there were ideas in place to imbed IPv4 addresses into IPv6 packets at a lower layer, but those ideas were canned because they required essentially importing the pre-existing IPv4 BGP routing tables into IPv6, and network operators wanted not only a clean routing solution, but one that was going to clean up the global prefix advertisement space.

So, being that IPv6 was largely created by network operators, a solution was chosen that would allow themselves to cleanly implement IPv6 (once you get the firmware updates, running a dual-stack backbone is actually really easy), and as the backbones could route the traffic, endpoints would deal with both existing.

From a deployment standpoint is basically breaks down to:

1. Do we want to design a protocol that is fast to deploy by backbone providers while continuing to maintain the stability of the existing network? Or,
2. Do we want to design a protocol that is easily interoperable between endpoints?

The designers picked option 1, believing that having a network up fast first and letting endpoints migrate slowly over to it was preferable to spending a ton more time getting a fully backwards-compatible network going so that people could switch really quick. Was that the right answer? I don't know. But we're living with option 1 today, let's see what endpoints can do about it.

Although I agree with your points , your post has kind of fallen into the NAT trap itself.

When most people talk about security through NAT, it's never been about "addressability". It's been about reachability. NAT offered a convenient means of deploying a default security policy that says "people secured by me can get out, but noone can get in". There's no reason whatsoever that default firewall/router policy at both the corporate and consumer levels can do this with IPv6 very easily with a couple of canned policies. In fact, people wishing to seem "ultra-secure" can still use their firewall as a transparent proxy for their outbound connections, thus making all of their normal traffic still look to come from the router/firewall in question! With IPv6, firewall/router policy could stay exactly the same, with one key feature: everyone has a unique address.

In fact, people wishing to use uPNP to make dynamic firewall policy changes can still do so! Except that instead of using oddball port mappings, we can just route the same standard port over to the proper address. Done. There's nothing inherently wrong with uPNP for consumers wishing to maintain decent security without needing to know the details on how the security policy works, but with IPv6 it's now about real security, not getting around address scarcity.

As stated above, I agree that making every host internet reachable is not an option, but making every host internet addressable is. People can choose at that point to continue to use NAT/Transparent proxy services to mask the true source of requests, or they may not. At least it's a choice. As for me, I'll make every one of my hosts internet reachable with a decent security policy and take advantage of all of the benefits both in capability and in troubleshooting, thank you very much. :)

You're precisely correct. However, this problem has nothing to do with externally accessible IP addresses. It's about connectivity and global uniqueness.

Let's say that I run the network for small company A. We used 10. private addresses for our network layout. My company get's bought by slightly bigger company B, that also uses 10. address space for their network. In all likelyhood, we're going to have address conflicts. So, I have 3 choices for integrating the 2 networks:

1. Renumber company A
2. Renumber company B.
3. Employ some kind of odd-ball double-NAT solution that makes both companies appear to have unique addresses from the other's perspective.

You can very easily see that the lack of globally unique IP addresses in this situation has created a huge mess that takes a lot of time and money to resolve. If both company A and company B used globally-unique IP address (v4 or v6!), this would have never been a problem. And both companies can very easily hide internally accessible and externally accessible hosts via routing and firewall policy.

In the company I work for, we deploy a VPN solution to allow 2000+ data gateways to connect to us to deliver data. Because each data gateway resides in a unique network often addressed via non-routable IPv4 addresses, I can never trust that the VPN IP that I assign to this data gateway will not conflict with the local network on which this is deployed. So, I got globally unique addresses from ARIN to do it. Guess what? I don't even advertise that route over BGP to the public internet! I only route it via my local AS. When people gather statistics by IPv4 usage, consider that there are quite a few of us who need globally unique IP space, but will never route that out publicly.

IPv6 is designed to provide a global pool of unique addresses so large that everyone can have a globally unique addresses, regardless of how one wishes to use it. This means that networks become an issue of connectivity, not one of address management.

The IPv6 working group almost got caught up in NAT mania: They initially created a reserved IPv6 space called "site local", which was designed to be treated in the exact same way as the current private address space. On further consideration, though, the working group decided that any "private" addresses are just silly and create more headache than what they are worth. The concept of "site local" simply means "I'm not going to advertise this route publicly". If you don't want to advertise your network over the public Internet, then just don't. Take your globally unique space and have fun with it.