Channel security in SQL Server

I've recently been looking into ways of securing the channel between a client and SQL Server. Given that SQL Server supports integrated authentication (integrated security=sspi) you'd think that the native TCP/IP library would be able to use SSPI to sign and seal the channel. But they don't, and I find that really odd.

Look, they tell you, if you want to use Kerberos to secure the channel, use the multiprotocol library. That puts another layer between you and SQL Server - now you're communicating over RPC, which can be configured to use SSPI to MAC protect and encrypt the channel. But why do I have to use RPC to get this? Why doesn't the native TCP/IP driver provide these basic protections?

And furthermore, I love the mysterious little caveat you'll find when you go read about using the multiprotocol encryption feature:

Use Multiprotocol encryption only for compatibility with existing systems. The Secure Sockets Layer (SSL) encryption that can be enabled using the Server Network Utility (after running Setup) is a more comprehensive encryption solution.

Oh, and this is a nice limitation as well:

The Multiprotocol Net-Library does not support named instances of SQL Server 2000. You can use the Multiprotocol Net-Library to connect to the default instance of SQL Server on a computer, but you cannot connect to any named instances.

Why am I bugged by this? Why don't I just use SSL and get in line with everyone else? Because setting up SSL connections is considerably slower than setting up Kerberos connections (think public key operations in SSL versus purely symmetrical operations with Kerb), and it requires certificates and PKI where Kerberos is already built right in to my domain infrastructure.

I want REAL Kerberos support. Not just authentication, but integrity and confidentiality too. And I want it built right in to the native network library for TCP/IP. Is that too much to ask? If someone can tell me this is coming in Yukon, I'd be a very happy camper indeed.