X.509 is wide and versatile and, in theory, anything goes.
In practice, I assume that you are talking about a SSL/TLS situation, probably as part of a HTTPS web site. The server sends his certificate (that the client validates), and then, the server asks the client to also show a certificate, which the server will validate.
In that situation, there cannot be much client-specific data that the server may validate. The important point is that validation of the client certificate happens on the server (necessarily: the certificate from the client is about convincing the server). So, if the server wants to validate some client-specific data (e.g. IP address) then the server must have access to an apparent client IP address, and see if that matches what would be written in the certificate. However, in the HTTPS ecosystem, NAT and proxies happen. Therefore, the client "true" IP address cannot be reliably obtained by the server (e.g. my true IP address is 10.0.1.101, but that's not what an HTTPS server would see, because I am behind both a NAT and a SOCKS proxy). So there is nothing for the server to validate.
In existing, deployed systems, SSL/TLS servers do not commonly validate client certificates with regards to client-specific information. I have never seen it. Instead, the server validates the certificate in abstracto (the whole signature-by-CA business, up to a root CA), regardless the apparent provenance of the incoming connection. And if the certificate validates, then the user identity is extracted from the certificate (using a server-specific method, but IIS will tend to look at the Subject Alt Name extension and extract the 'UPN', to match against what is in his Active Directory server) and the server is content with that.
Actually that's quite similar to what happens in the other direction: validation of the server certificate by the client. The client wants to make sure that it talks to the right server, so it verifies that the server's name is indeed present in the certificate. The server's IP address, on the other hand, is not in the server's certificate; it was resolved through the DNS. From the point of view of the SSL client, as far as security is concerned, how the data flows is irrelevant; it could go to any IP address or be transmitted on an IP-less serial link or be transported on the back of camels.
Short answer: your client certificate is (probably) not bound to a specific machine, if only because enforcing such a binding would be, at best, difficult. You can transfer it from one machine to another (as long as you transfer the certificate with its private key, of course).
