There are 2 IDs in an IKE exchange. The ID in phase 1 is used for authentication of the remote VPN gateway (i.e., to identify and verify the peer gateway). This ID can be one of many types. Right now Netscreen supports:
ID_IPV4_ADDR (e.g., 216.59.109.152)
ID_FQDN (e.g., www.juniper.net)
ID_USER_FQDN (e.g., dklein@juniper.net)
ID_DER_ASN1_DN ( Distinguished Name in Certificate)

There is another ID used in phase 2 (Quick Mode). This ID is also referred to as "proxy id". This ID (proxy id) is retrieved from the pre-configured policy and is used to make sure both gateways have the same policy (i.e., firewall filter). This ID can be one of:
ID_IPV4-ADDR
ID_IPV4_SUBNET
ID_IPV4_RANGE (which NetScreen does not support now)

No other ID type can be used in the proxy id.

The ISAKMP id modes are defined in RFC 2407 section 4.6.2.1.

---excerpt from RFC 2407 ------->

4.6.2.1 Identification Type Values
The following table lists the assigned values for the Identification Type field found in the Identification Payload.

ID Type Value

RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11

For types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header. When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange.

4.6.2.2 ID_IPV4_ADDR
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.

4.6.2.3 ID_FQDN
The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators.

4.6.2.4 ID_USER_FQDN
The ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should not contain any terminators.

4.6.2.5 ID_IPV4_ADDR_SUBNET
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.6 ID_IPV6_ADDR
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6address.

4.6.2.7 ID_IPV6_ADDR_SUBNET
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.8 ID_IPV4_ADDR_RANGE
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.

4.6.2.9 ID_IPV6_ADDR_RANGE
The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.

4.6.2.10 ID_DER_ASN1_DN
The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA.

4.6.2.11 ID_DER_ASN1_GN
The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA.

4.6.2.12 ID_KEY_ID
The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre-shared key should be used to authenticate Aggressive mode negotiations.