Thanks Jim for the comprehensive reply - very useful.
So it basically boils down to representing discontiguous address ranges in one go rather than individually?
Pretty much. It just gives flexibility in that you can compare and "mask" bits in various positions, and if it works in the code and ASICs as I presume it does, it would be more efficient seeing that you'd need fewer ACLs do to the same thing in certain cases.
From the scenerios you describe it does make you wonder why Cisco have taken a backwards step in this regard, particularly if there's performance hit as you posit? Or do think it is more a case of the (im)maturity of IPv6 support and that this functionality will come one day?
There could be a lot of reasons for them to do the prefix length only thing. It could be that the ASICs or code aren't implemented the way I think they are (perhaps they use TCAM or something). Or it could just be to make things more consistent (since the pref-length thing is used for many other things, routes, etc). Or maybe just fashion (netmasks and wildmasks are "old hat" and CIDR/pref length notation is the "new" way). Or maybe they figured that people wouldn't need to do the sorts of matching in my examples often enough to require wildcards. After all, prefix lengths cover typical ACL matches just fine.
Note that the prefix length vs. wildcard mask itself shouldn't directly cause any sort of performance hit, since as I mentioned, the prefix length matching code could be implemented the same way, just generating an AND mask from the address/preflength pair (at configuration time, not run time) and doing the comparison the same way. A performance hit would only arise from a case of requiring way more ACLs for a particular sort of match (as in my examples) than the wildcard ACL would require.
IMHO, since there are so many bits in an IPv6 address, it would seem to me
that based on the examples I give, plus others I probably haven't thought of yet, that having the ability to do both wildcard and/or preflength style ACL clauses would be a good thing. But there may be technical reasons why they may prefer the latter.
I have no idea whether we'll see the return of wildcards or not. My guess, if people find the need to do those sorts of comparisons then we'll see their return, or some other mechanism such as chaining ACLs based matching, or doing multiple preflength compares in a single ACL using logical operators, or something like that). It'd probably depend on what is closest to the underlying hardware. But to me, not being a router hardware engineer, a simple bitwise AND followed by a compare would seem to be the fastest, since these are super-basic functions of any CPU or ASIC. But as I said, I'm not a EE type working on router ASICs/hardware, so my presumptions could be way off.