Lets start from the kernel part:
- Device mapper is a kernel driver that allows creating new block devices from existing ones. It provides multiple additional features like RAID, caching or encryption through so called targets.
- dm-crypt is a device mapper target that provides transparent encryption. This means you can create a block device on top of your disk or partition and everything you write to this new device mapper device will be encrypted before the data is actually written to the disk. And vice versa for reading: if you read from the device, the data is read from the disk and decrypted before returning to you.
- dm-integrity is also a device mapper target, this one has a special metadata area for each block which are used to store checksum of the data block. This allows detection of data corruption.
Now the userspace level:
You can use device mapper directly, but it's not user friendly. Say you want to use dm-crypt directly -- to access the data you need to know the encryption algorithm, used IV and of course the key (which isn't short and easy to remember). It wouldn't be very practical to ask for these during boot.
That's where LUKS comes in. It provides two things: header and way to store (and manage) keys. Header allows system to identify the device as LUKS and contains all the metadata needed to work with the device. And key management allows you to safely store the encryption key on the disk, protected by easy to remember passphrase (or key file, TPM, FIDO token, etc.).
So the LUKS format only gives system all the information needed to correctly set the device mapper device up. You'll most likely use cryptsetup for that -- tool and library that can read the LUKS metadata, decrypt the key stored in there and correctly create the DM device.
The difference between LUKSv1 and LUKSv2 is in the format of the metadata. LUKSv2 adds some features, one of them is the authenticated encryption, which is combination of dm-crypt and dm-integrity -- integrity provides the checksums and crypt makes sure the checksums are also encrypted so it isn't possible to simply change both data and the cheksum hiding the change (plain integrity doesn't protect against this, it can be used only to protect about random data changes like bit rot). So authenticated encryption is provided by combining two technologies with LUKSv2 -- the metadata in the LUKSv2 header tell how the two device mapper targets needs to be configured and combined to get the data.
