Both GCM and CCM turn a regular block cipher into what we call an AEAD (authenticated encryption with additional data). Both algorithms provide encryption with what is effectively counter (CTR) mode and a MAC, combined into one algorithm with a single nonce and key.
The difference in how CCM and GCM authenticate the data is the major difference in the modes. CCM uses a variant of CBC-MAC to authenticate the data and GCM uses a polynomial (Carter-Wegman-style) MAC. Due to the requirements of using CBC-MAC in a secure way, the length is prefixed to the data, so with CCM one must typically know the data length ahead of time, whereas GCM doesn't have this problem.
Both algorithms require the use of a unique nonce plus a symmetric key. Anyone who knows the symmetric key can encrypt and decrypt data as well as create and verify valid messages.
The reason that ECB, CBC, CTR, CFB, OFB, and the like don't provide authenticity is that they only encrypt the data. An AEAD produces encrypted data plus a tag, which is traditionally appended to the message. This tag (and its correct verification) provides authenticity, and can be thought of as the output of a MAC. However, the five modes I mentioned above don't provide a tag, and as a result, they don't provide any authenticity. As a result, they should be used with a standalone MAC, such as HMAC with a secure hash function, in almost all cases.
The additional data is usually unencrypted for practical reasons. For example, in TLS, the packet header and sequence number are authenticated, but the packet header cannot be encrypted (since it's needed to parse the data properly) and the sequence number is not sent at all (it's an increasing integer kept as part of the state). This approach prevents replay attacks and, in some protocols, things like protocol downgrades. In any event, any change to either the encrypted message or the additional data will cause the tag to fail to verify with very high probability, and thus the message will be rejected.
