Data Contracts form part of the public API your service exposes. Despite being represented in code by plain CLR classes (albeit decorated with an attribute) - do not be fooled - they are really serialized on the wire in to strings for consumption by the client/server. As such, from a service orientated view point, we must move away from the temptation to associated them to Object Orientated concepts.
Using Inheritance, Interface abstractions and nested classes all deal with OO concepts (polymorphism, abstraction and access), and even though some/all of these are technically possible in WCF (e.g. through the KnownTypes
attribute) - just because you can do something - it doesn't mean you should.
I have no doubt there is some way to achieve the correct serialization behaviour to get WCF to recognize nested classes. However, in doing so I suspect you are going against the grain of service orientation - and consequently not using the full power of your service orientated architecture.