Size of IV in AES-GCM according to RFC 4106 RFC 4106 specifies about nonce. It contains a salt of size 4 octets and an iv of size 8 octets. Further, RFC specifies that salt is assigned at the beginning of the security associations which is established through Internet Key Exchange (IKE) and salt value is constant. But all most all of the implementations and descriptions found about AES-GCM specifies iv as 12 octets and there is no consideration of salt value.  

AES-GCM takes inputs as a secret key, an IV, a plaintext and Additional Authenticated Data (AAD). AES-GMAC is a variant of AES-GCM which provides authentication of data by keeping plaintext as zero bits. 

Other questions I have regarding AES-GCM mode are.


I know that AES-GCM can be used for authentication of data by Can we use AES-GCM mode only for encryption by ignoring authentication?
Is it mandatory to use iv for encryption using AES-GCM?  
What are the allowable variants of AES-GMAC like AES-GMAC128, AES-GMAC256 etc. ?
kelalaka answered your questions, however I do believe there are things that could use some clarification:


  RFC 4106 specifies about nonce. It contains a salt of size 4 octets and an iv of size 8 octets. Further, RFC specifies that salt is assigned at the beginning of the security associations which is established through Internet Key Exchange (IKE) and salt value is constant. But all most all of the implementations and descriptions found about AES-GCM specifies iv as 12 octets and there is no consideration of salt value.


First, a clarification on terminology (at least, the terminology I'll be using in my answer below):


Nonce - this is the (typically 96 bit) value passed to the GCM routine
IV - this is the value within the packet - IPsec with GCM uses 64 bit IVs
Salt - this is the additional value that is included with the recipe to generate the nonce.


RFC 4106 is specifically about how to use GCM within IPsec; as such, it has a recipe for generating the nonce (which you refer to as an 'iv') that GCM requires.  It does it by talking 8 bytes chosen by the encryptor (which he places in the 'iv field' within the packet, and which the decryptor extracts from the packet), and 4 bytes for the key derivation (the 'salt') and concatenating them.

This is specific to IPsec (actually, TLS's use of GCM does the same thing); other protocols which use GCM may generate (and communicate) their nonces in a different way.  Because a cryptographical routine is typically protocol agnostic, they would not have the IPsec-specific recipe built in.  Instead, they would assume that something protocol specific would generate the nonce, and pass the entire nonce in.

As for why IPsec uses this specific recipe to generate GCM nonces, well, it's to frustrate potential multitarget attacks.  Suppose that the attacker has a large number of GCM encrypted sessions, and that he would like to recover the contents of one of them (and doesn't really care which one it is).  Further suppose that the GCM implementations use the same IVs for each session (e.g. the first encrypted packet might always use an IV of 0).  Then, what the attacker might try to do is guess an AES key, and generate the GCM privacy keystream, and see if that the correct keystream for the initial packet for any session (that turns out to be efficient with plausible assumptions).  If he could do that, that would mean that, for a 128 bit key and $N$ sessions, his expected work effort to break one of the sessions is $2^{128}/N$ trial decryptions, which is less than we want.  However, by including the 32 bit salt (which varies between sessions), this expected work effort increases to $2^{160}/N$ (because he has to guess the salt as well as the key); in particular, this means that this multitarget attack is actually less efficient than a simple brute force attack unless $N &gt; 2^{32}$, which is quite a lot.  Note that this salt doesn't actually help against brute force attacks against a single session; it doesn't hurt either.  And, it doesn't really have to be secret (however, there's no particular reason we have to go out of our way to publish it either...)