I'm assuming the threat model is that there may be a man-in-the-middle attacker between Alice and Bob, and that Alice and Bob are not on the same trusted sub-net. That's what SSL/TLS is designed to protect against, and that's why Alice should check Bob's certificate in your example (at least).
From Bob's point of view, checking that Alice's request come from a known IP address isn't of much use. Attackers could forge and alter packets to make them look like they come from the IP address they wish. Subsequently, DNS lookups are useless too: all you'd need is to make sure you forge the packets to use an IP address with the correct DNS entry.
When Bob requests a client-certificate from Alice during SSL/TLS handshake, this will also make Alice send her certificate and use her private key during the SSL/TLS handshake to assert her identity. When the handshake has completed successfully, Bob will then know that Alice has the private key for that certificate and will have to verify it trusts this certificate.
Whether or not the request comes from behind a proxy or not doesn't matter when you're using SSL/TLS. An HTTP proxy merely tunnels the SSL/TLS connection from the original client to the target server.
What matters to Bob is how he's going to verify Alice's certificate. Typically, this will be done using a PKI in the same way as Alice verified Bob's certificate, although this needs not be the same CA as Bob's (it needs to be something that Bob trusts). Note that this doesn't need to be using a PKI either. It's possible to verify the certificate against a given list (if Alice and Bob have met before, for example), but this can be a bit more complex since Bob may have to tweak the accepted issuers list it sends (e.g. send an empty one, which is explicitly allowed by TLS 1.1, but not specified either way in previous versions, see Certificate Request message) and use custom code to verify that certificate. (I've implemented this sort of scheme in the past and it works fine.)
There is an exception to this when using what I'd call "MITM proxy servers", that is proxy servers that are configured to spoof the actual SSL/TLS server by inserting their own certificate (see Squid's SSL Bump). In this case the certificate Alice sees wouldn't come from Diginotar, but from another CA (typically a corporate CA when this is done on a corporate LAN).
Although Alice might allow herself to trust such a MITM proxy, using SSL/TLS client-certificate authentication would make Bob realise there is a MITM and the connection would fail. This is because Alice is supposed to sign the entire SSL/TLS handshake (as seen by both Alice and Bob) in her
CertificateVerify message to authenticate with a client-certificate. Since the MITM proxy would have replaced Bob's certificate, the signatures sent by Alice and Bob wouldn't match.