As Richard points out, there is *no* reason to configure /64s on point-to-point links, and there are obvious disadvantages. The "RFC wavers" are downright stupid to suggest otherwise.
As for IXP LANs, I predict that one of two things will happen: either one or more major IXPs will be subject to NDP DoS and will decide to shrink their subnet size, allowing others to follow suit; or vendors will make NDP inspection work and be configurable enough to prevent most problems. Again, Cisco has already added a knob to some platforms which allows you to steer the failure mode. Interfaces will fail regardless of what you do; the Cisco knob just lets you decide to break NDP on only the interface(s) subject to attack instead of on the entire box. In any case, I don't judge static NDP entries on IXP LANs to be a practical long-term solution. There are obvious disadvantages to that.
And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon. If you are a service provider where practically all of your links are point to points, sure.
If your network is entirely made up of backbone routers with fairly static neighbors, your strategy can certainly work with a bit of extra effort and a vendor box that doesn't do entirely crazy things.
Where that is done is primarily on a backbone section of the network and where I connect to public peering points. I add static entries for the specific peers I communicate with. Yes, it does take a little maintenance when a peer changes out some gear or moves to a different port on their gear but that doesn't happen all that often and is a compromise I am willing to make in exchange for some added protection. It also protects against someone who I am not peering with on that same switch fat-fingering an IP address during some maintenance and accidently configuring their gear with the same IP as someone I *am* peering with. I won't even see it if I have a static neighbor (the same thing is also done with v4 on public peering switches with static ARP entries, too).
If you have customers (those pesky customers!) they may not be so comfortable having to open a ticket and feel like they are troubleshooting a problem you've caused them because you have configured a static NDP entry facing them.
Right, if I had dozens of point-to-points with gear that is constantly changing at the other end, yeah. I agree. I might then consider that approach. But in this case I can only speak about my own stuff and what is the best solution for one specific application might not be the best solution for someone else. I am not trying to say that this solution is best for everyone, I am simply pointing out a solution that others might find useful depending on their application.
I have been talking to smart people about this problem for nearly ten years, and I have never heard a practical solution that doesn't involve some kind of persistent "sticky NDP" which refuses to make discovery requests to the LAN for addresses which have never been seen from the LAN. I've also never seen a practical idea for preventing malicious hosts on the LAN from filling the table that doesn't involve NDP inspection at the access port, some kind of database (e.g. RADIUS/etc) or additional configuration in the router, or proposals that would simply change the failure mode (e.g. rate-limit knobs.)
Yeah, it's a tough nut to crack. I do agree that 64-bit host addressing is just too big. The reason is that it even allows you to configure more IPs on a single subnet legitimately than the network gear can handle. The notion of "we are going to give you a subnet with 8 bazillion possible addresses, but don't try to use more than half a million of them or you will melt your network gear" seems quite idiotic, actually. So you have a huge address space that you actually can't use much of (relative to the size of the space) and it creates a stability risk. We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore.
You'll notice that there have been several discussions about this on NANOG and other mailing lists, most of which include some "RFC wavers," some people saying "the sky is falling," and some guys in-between who think their vendor's box will fail gracefully or that NDP learning not functioning for some or all interfaces is not bad as long as the box doesn't evict busy entries. I suggest all the folks in the middle ask themselves why Cisco added a knob *just to control the failure mode.* This is a real problem, and the current, practical fix is simply to not configure /64.
And again, are you talking about all the way down to the host subnet level? I suppose I could configure server farms in /112 or even /96 (/96 has some appeal for other reasons mostly having to do with multicast) but then I would wonder how many bugs that would flush out of OS v6 stacks. Something will have to evolve to handle this problem because I agree with you, it is going to be a major issue at some point. It might just be as simple as a host doing what amounts to a gratuitous announcement when an IP is assigned to an interface (and some kind of withdrawal announcement when the address is removed). If a packet arrived from an interface off the host's subnet for an IP address that is not in the neighbor table at all (even stale ones), then maybe the router simply drops the packet. Leave it up to the hosts themselves to keep their information current on the network even when they aren't passing traffic. That doesn't protect against rogue hosts but there might be ways around that, too, or at least limiting the damage a rogue host can cause. So any packet arriving on a router for a local subnet, if that address isn't already in the neighbor table, drop it on the floor or return an "unreachable" or whatever. Something will have to be done at some point ... soon.