tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2408

 
 
 

Internet Security Association and Key Management Protocol (ISAKMP)

Part 2 of 4, p. 21 to 44
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 21 
3 ISAKMP Payloads

   ISAKMP payloads provide modular building blocks for constructing
   ISAKMP messages.  The presence and ordering of payloads in ISAKMP is
   defined by and dependent upon the Exchange Type Field located in the
   ISAKMP Header (see Figure 2).  The ISAKMP payload types are discussed
   in sections 3.4 through 3.15.  The descriptions of the ISAKMP
   payloads, messages, and exchanges (see Section 4) are shown using
   network octet ordering.

3.1 ISAKMP Header Format

   An ISAKMP message has a fixed header format, shown in Figure 2,
   followed by a variable number of payloads.  A fixed header simplifies
   parsing, providing the benefit of protocol parsing software that is
   less complex and easier to implement.  The fixed header contains the
   information required by the protocol to maintain state, process
   payloads and possibly prevent denial of service or replay attacks.

   The ISAKMP Header fields are defined as follows:

    o  Initiator Cookie (8 octets) - Cookie of entity that initiated SA
       establishment, SA notification, or SA deletion.

    o  Responder Cookie (8 octets) - Cookie of entity that is responding
       to an SA establishment request, SA notification, or SA deletion.

Top      Up      ToC       Page 22 
                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Initiator                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Responder                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Message ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Length                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 2:  ISAKMP Header Format

    o  Next Payload (1 octet) - Indicates the type of the first payload
       in the message.  The format for each payload is defined in
       sections 3.4 through 3.16.  The processing for the payloads is
       defined in section 5.


                        Next Payload Type       Value
                    NONE                           0
                    Security Association (SA)      1
                    Proposal (P)                   2
                    Transform (T)                  3
                    Key Exchange (KE)              4
                    Identification (ID)            5
                    Certificate (CERT)             6
                    Certificate Request (CR)       7
                    Hash (HASH)                    8
                    Signature (SIG)                9
                    Nonce (NONCE)                 10
                    Notification (N)              11
                    Delete (D)                    12
                    Vendor ID (VID)               13
                    RESERVED                   14 - 127
                    Private USE               128 - 255

    o  Major Version (4 bits) - indicates the major version of the ISAKMP
       protocol in use.  Implementations based on this version of the
       ISAKMP Internet-Draft MUST set the Major Version to 1.
       Implementations based on previous versions of ISAKMP Internet-
       Drafts MUST set the Major Version to 0.  Implementations SHOULD

Top      Up      ToC       Page 23 
       never accept packets with a major version number larger than its
       own.

    o  Minor Version (4 bits) - indicates the minor version of the
       ISAKMP protocol in use.  Implementations based on this version of
       the ISAKMP Internet-Draft MUST set the Minor Version to 0.
       Implementations based on previous versions of ISAKMP Internet-
       Drafts MUST set the Minor Version to 1.  Implementations SHOULD
       never accept packets with a minor version number larger than its
       own, given the major version numbers are identical.

    o  Exchange Type (1 octet) - indicates the type of exchange being
       used.  This dictates the message and payload orderings in the
       ISAKMP exchanges.


                            Exchange Type      Value
                         NONE                    0
                         Base                    1
                         Identity Protection     2
                         Authentication Only     3
                         Aggressive              4
                         Informational           5
                         ISAKMP Future Use     6 - 31
                         DOI Specific Use     32 - 239
                         Private Use         240 - 255

    o  Flags (1 octet) - indicates specific options that are set for the
       ISAKMP exchange.  The flags listed below are specified in the
       Flags field beginning with the least significant bit, i.e the
       Encryption bit is bit 0 of the Flags field, the Commit bit is bit
       1 of the Flags field, and the Authentication Only bit is bit 2 of
       the Flags field.  The remaining bits of the Flags field MUST be
       set to 0 prior to transmission.

      --  E(ncryption Bit) (1 bit) - If set (1), all payloads following
          the header are encrypted using the encryption algorithm
          identified in the ISAKMP SA. The ISAKMP SA Identifier is the
          combination of the initiator and responder cookie.  It is
          RECOMMENDED that encryption of communications be done as soon
          as possible between the peers.  For all ISAKMP exchanges
          described in section 4.1, the encryption SHOULD begin after
          both parties have exchanged Key Exchange payloads.  If the
          E(ncryption Bit) is not set (0), the payloads are not
          encrypted.

Top      Up      ToC       Page 24 
      -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange
          synchronization.  It is used to ensure that encrypted material
          is not received prior to completion of the SA establishment.
          The Commit Bit can be set (at anytime) by either party
          participating in the SA establishment, and can be used during
          both phases of an ISAKMP SA establishment.  However, the value
          MUST be reset after the Phase 1 negotiation.  If set(1), the
          entity which did not set the Commit Bit MUST wait for an
          Informational Exchange containing a Notify payload (with the
          CONNECTED Notify Message) from the entity which set the Commit
          Bit.  In this instance, the Message ID field of the
          Informational Exchange MUST contain the Message ID of the
          original ISAKMP Phase 2 SA negotiation.  This is done to
          ensure that the Informational Exchange with the CONNECTED
          Notify Message can be associated with the correct Phase 2 SA.
          The receipt and processing of the Informational Exchange
          indicates that the SA establishment was successful and either
          entity can now proceed with encrypted traffic communication.
          In addition to synchronizing key exchange, the Commit Bit can
          be used to protect against loss of transmissions over
          unreliable networks and guard against the need for multiple
          re-transmissions.

          NOTE: It is always possible that the final message of an
          exchange can be lost.  In this case, the entity expecting to
          receive the final message of an exchange would receive the
          Phase 2 SA negotiation message following a Phase 1 exchange or
          encrypted traffic following a Phase 2 exchange.  Handling of
          this situation is not standardized, but we propose the
          following possibilities.  If the entity awaiting the
          Informational Exchange can verify the received message (i.e.
          Phase 2 SA negotiation message or encrypted traffic), then
          they MAY consider the SA was established and continue
          processing.  The other option is to retransmit the last ISAKMP
          message to force the other entity to retransmit the final
          message.  This suggests that implementations may consider
          retaining the last message (locally) until they are sure the
          SA is established.

      --  A(uthentication Only Bit) (1 bit) - This bit is intended for
          use with the Informational Exchange with a Notify payload and
          will allow the transmission of information with integrity
          checking, but no encryption (e.g.  "emergency mode").  Section
          4.8 states that a Phase 2 Informational Exchange MUST be sent
          under the protection of an ISAKMP SA. This is the only
          exception to that policy.  If the Authentication Only bit is
          set (1), only authentication security services will be applied
          to the entire Notify payload of the Informational Exchange and

Top      Up      ToC       Page 25 
          the payload will not be encrypted.

    o  Message ID (4 octets) - Unique Message Identifier used to
       identify protocol state during Phase 2 negotiations.  This value
       is randomly generated by the initiator of the Phase 2
       negotiation.  In the event of simultaneous SA establishments
       (i.e.  collisions), the value of this field will likely be
       different because they are independently generated and, thus, two
       security associations will progress toward establishment.
       However, it is unlikely there will be absolute simultaneous
       establishments.  During Phase 1 negotiations, the value MUST be
       set to 0.

    o  Length (4 octets) - Length of total message (header + payloads)
       in octets.  Encryption can expand the size of an ISAKMP message.

3.2 Generic Payload Header

   Each ISAKMP payload defined in sections 3.4 through 3.16 begins with
   a generic header, shown in Figure 3, which provides a payload
   "chaining" capability and clearly defines the boundaries of a
   payload.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !   RESERVED    !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3:  Generic Payload Header

   The Generic Payload Header fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.  This field provides
       the "chaining" capability.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

3.3 Data Attributes

   There are several instances within ISAKMP where it is necessary to
   represent Data Attributes.  An example of this is the Security
   Association (SA) Attributes contained in the Transform payload

Top      Up      ToC       Page 26 
   (described in section 3.6).  These Data Attributes are not an ISAKMP
   payload, but are contained within ISAKMP payloads.  The format of the
   Data Attributes provides the flexibility for representation of many
   different types of information.  There can be multiple Data
   Attributes within a payload.  The length of the Data Attributes will
   either be 4 octets or defined by the Attribute Length field.  This is
   done using the Attribute Format bit described below.  Specific
   information about the attributes for each domain will be described in
   a DOI document, e.g.  IPSEC DOI [IPDOI].

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !A!       Attribute Type        !    AF=0  Attribute Length     !
     !F!                             !    AF=1  Attribute Value      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                   AF=0  Attribute Value                       .
     .                   AF=1  Not Transmitted                       .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 4:  Data Attributes

   The Data Attributes fields are defined as follows:

    o  Attribute Type (2 octets) - Unique identifier for each type of
       attribute.  These attributes are defined as part of the DOI-
       specific information.

       The most significant bit, or Attribute Format (AF), indicates
       whether the data attributes follow the Type/Length/Value (TLV)
       format or a shortened Type/Value (TV) format.  If the AF bit is a
       zero (0), then the Data Attributes are of the Type/Length/Value
       (TLV) form.  If the AF bit is a one (1), then the Data Attributes
       are of the Type/Value form.

    o  Attribute Length (2 octets) - Length in octets of the Attribute
       Value.  When the AF bit is a one (1), the Attribute Value is only
       2 octets and the Attribute Length field is not present.

    o  Attribute Value (variable length) - Value of the attribute
       associated with the DOI-specific Attribute Type.  If the AF bit
       is a zero (0), this field has a variable length defined by the
       Attribute Length field.  If the AF bit is a one (1), the
       Attribute Value has a length of 2 octets.

Top      Up      ToC       Page 27 
3.4 Security Association Payload

   The Security Association Payload is used to negotiate security
   attributes and to indicate the Domain of Interpretation (DOI) and
   Situation under which the negotiation is taking place.  Figure 5
   shows the format of the Security Association payload.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                           Situation                           ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 5:  Security Association Payload

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.  This field MUST NOT
       contain the values for the Proposal or Transform payloads as they
       are considered part of the security association negotiation.  For
       example, this field would contain the value "10" (Nonce payload)
       in the first message of a Base Exchange (see Section 4.4) and the
       value "0" in the first message of an Identity Protect Exchange
       (see Section 4.5).

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the entire
       Security Association payload, including the SA payload, all
       Proposal payloads, and all Transform payloads associated with the
       proposed Security Association.

    o  Domain of Interpretation (4 octets) - Identifies the DOI (as
       described in Section 2.1) under which this negotiation is taking
       place.  The DOI is a 32-bit unsigned integer.  A DOI value of 0
       during a Phase 1 exchange specifies a Generic ISAKMP SA which can
       be used for any protocol during the Phase 2 exchange.  The
       necessary SA Attributes are defined in A.4.  A DOI value of 1 is
       assigned to the IPsec DOI [IPDOI].  All other DOI values are
       reserved to IANA for future use.  IANA will not normally assign a
       DOI value without referencing some public specification, such as

Top      Up      ToC       Page 28 
       an Internet RFC. Other DOI's can be defined using the description
       in appendix B.  This field MUST be present within the Security
       Association payload.

    o  Situation (variable length) - A DOI-specific field that
       identifies the situation under which this negotiation is taking
       place.  The Situation is used to make policy decisions regarding
       the security attributes being negotiated.  Specifics for the IETF
       IP Security DOI Situation are detailed in [IPDOI].  This field
       MUST be present within the Security Association payload.

3.5 Proposal Payload

   The Proposal Payload contains information used during Security
   Association negotiation.  The proposal consists of security
   mechanisms, or transforms, to be used to secure the communications
   channel.  Figure 6 shows the format of the Proposal Payload.  A
   description of its use can be found in section 4.2.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Proposal #   !  Protocol-Id  !    SPI Size   !# of Transforms!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SPI (variable)                         !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 6:  Proposal Payload Format

   The Proposal Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  This field MUST only contain the
       value "2" or "0".  If there are additional Proposal payloads in
       the message, then this field will be 2.  If the current Proposal
       payload is the last within the security association proposal,
       then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the entire
       Proposal payload, including generic payload header, the Proposal
       payload, and all Transform payloads associated with this
       proposal.  In the event there are multiple proposals with the
       same proposal number (see section 4.2), the Payload Length field

Top      Up      ToC       Page 29 
       only applies to the current Proposal payload and not to all
       Proposal payloads.

    o  Proposal # (1 octet) - Identifies the Proposal number for the
       current payload.  A description of the use of this field is found
       in section 4.2.

    o  Protocol-Id (1 octet) - Specifies the protocol identifier for the
       current negotiation.  Examples might include IPSEC ESP, IPSEC AH,
       OSPF, TLS, etc.

    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
       therefore, the SPI Size is irrelevant and MAY be from zero (0) to
       sixteen (16).  If the SPI Size is non-zero, the content of the
       SPI field MUST be ignored.  If the SPI Size is not a multiple of
       4 octets it will have some impact on the SPI field and the
       alignment of all payloads in the message.  The Domain of
       Interpretation (DOI) will dictate the SPI Size for other
       protocols.

    o  # of Transforms (1 octet) - Specifies the number of transforms
       for the Proposal.  Each of these is contained in a Transform
       payload.

    o  SPI (variable) - The sending entity's SPI. In the event the SPI
       Size is not a multiple of 4 octets, there is no padding applied
       to the payload, however, it can be applied at the end of the
       message.

   The payload type for the Proposal Payload is two (2).

3.6 Transform Payload

   The Transform Payload contains information used during Security
   Association negotiation.  The Transform payload consists of a
   specific security mechanism, or transforms, to be used to secure the
   communications channel.  The Transform payload also contains the
   security association attributes associated with the specific
   transform.  These SA attributes are DOI-specific.  Figure 7 shows the
   format of the Transform Payload.  A description of its use can be
   found in section 4.2.

Top      Up      ToC       Page 30 
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Transform #  !  Transform-Id !           RESERVED2           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                        SA Attributes                          ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 7:  Transform Payload Format

   The Transform Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  This field MUST only contain the
       value "3" or "0".  If there are additional Transform payloads in
       the proposal, then this field will be 3.  If the current
       Transform payload is the last within the proposal, then this
       field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header, Transform values,
       and all SA Attributes.

    o  Transform # (1 octet) - Identifies the Transform number for the
       current payload.  If there is more than one transform proposed
       for a specific protocol within the Proposal payload, then each
       Transform payload has a unique Transform number.  A description
       of the use of this field is found in section 4.2.

    o  Transform-Id (1 octet) - Specifies the Transform identifier for
       the protocol within the current proposal.  These transforms are
       defined by the DOI and are dependent on the protocol being
       negotiated.

    o  RESERVED2 (2 octets) - Unused, set to 0.

    o  SA Attributes (variable length) - This field contains the
       security association attributes as defined for the transform
       given in the Transform-Id field.  The SA Attributes SHOULD be
       represented using the Data Attributes format described in section
       3.3.  If the SA Attributes are not aligned on 4-byte boundaries,

Top      Up      ToC       Page 31 
       then subsequent payloads will not be aligned and any padding will
       be added at the end of the message to make the message 4-octet
       aligned.

   The payload type for the Transform Payload is three (3).

3.7 Key Exchange Payload

   The Key Exchange Payload supports a variety of key exchange
   techniques.  Example key exchanges are Oakley [Oakley], Diffie-
   Hellman, the enhanced Diffie-Hellman key exchange described in X9.42
   [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows
   the format of the Key Exchange payload.

   The Key Exchange Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       nextpayload in the message.  If the current payload is the last
       in the message, then this field will be 0.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                       Key Exchange Data                       ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 8:  Key Exchange Payload Format

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Key Exchange Data (variable length) - Data required to generate a
       session key.  The interpretation of this data is specified by the
       DOI and the associated Key Exchange algorithm.  This field may
       also contain pre-placed key indicators.

   The payload type for the Key Exchange Payload is four (4).

Top      Up      ToC       Page 32 
3.8 Identification Payload

   The Identification Payload contains DOI-specific data used to
   exchange identification information.  This information is used for
   determining the identities of communicating peers and may be used for
   determining authenticity of information.  Figure 9 shows the format
   of the Identification Payload.

   The Identification Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  ID Type (1 octet) - Specifies the type of Identification being
       used.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   ID Type     !             DOI Specific ID Data              !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                   Identification Data                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 9:  Identification Payload Format

       This field is DOI-dependent.

    o  DOI Specific ID Data (3 octets) - Contains DOI specific
       Identification data.  If unused, then this field MUST be set to
       0.

    o  Identification Data (variable length) - Contains identity
       information.  The values for this field are DOI-specific and the
       format is specified by the ID Type field.  Specific details for
       the IETF IP Security DOI Identification Data are detailed in
       [IPDOI].

Top      Up      ToC       Page 33 
   The payload type for the Identification Payload is five (5).

3.9 Certificate Payload

   The Certificate Payload provides a means to transport certificates or
   other certificate-related information via ISAKMP and can appear in
   any ISAKMP message.  Certificate payloads SHOULD be included in an
   exchange whenever an appropriate directory service (e.g.  Secure DNS
   [DNSSEC]) is not available to distribute certificates.  The
   Certificate payload MUST be accepted at any point during an exchange.
   Figure 10 shows the format of the Certificate Payload.

   NOTE: Certificate types and formats are not generally bound to a DOI
   - it is expected that there will only be a few certificate types, and
   that most DOIs will accept all of these types.

   The Certificate Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Cert Encoding !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                       Certificate Data                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 10:  Certificate Payload Format

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Certificate Encoding (1 octet) - This field indicates the type of
       certificate or certificate-related information contained in the
       Certificate Data field.

Top      Up      ToC       Page 34 
                          Certificate Type            Value
                  NONE                                   0
                  PKCS #7 wrapped X.509 certificate      1
                  PGP Certificate                        2
                  DNS Signed Key                         3
                  X.509 Certificate - Signature          4
                  X.509 Certificate - Key Exchange       5
                  Kerberos Tokens                        6
                  Certificate Revocation List (CRL)      7
                  Authority Revocation List (ARL)        8
                  SPKI Certificate                       9
                  X.509 Certificate - Attribute         10
                  RESERVED                           11 - 255

    o  Certificate Data (variable length) - Actual encoding of
       certificate data.  The type of certificate is indicated by the
       Certificate Encoding field.

   The payload type for the Certificate Payload is six (6).

3.10 Certificate Request Payload

   The Certificate Request Payload provides a means to request
   certificates via ISAKMP and can appear in any message.  Certificate
   Request payloads SHOULD be included in an exchange whenever an
   appropriate directory service (e.g.  Secure DNS [DNSSEC]) is not
   available to distribute certificates.  The Certificate Request
   payload MUST be accepted at any point during the exchange.  The
   responder to the Certificate Request payload MUST send its
   certificate, if certificates are supported, based on the values
   contained in the payload.  If multiple certificates are required,
   then multiple Certificate Request payloads SHOULD be transmitted.
   Figure 11 shows the format of the Certificate Request Payload.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Cert. Type   !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                    Certificate Authority                      ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 11:  Certificate Request Payload Format

Top      Up      ToC       Page 35 
   The Certificate Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Certificate Type (1 octet) - Contains an encoding of the type of
       certificate requested.  Acceptable values are listed in section
       3.9.

    o  Certificate Authority (variable length) - Contains an encoding of
       an acceptable certificate authority for the type of certificate
       requested.  As an example, for an X.509 certificate this field
       would contain the Distinguished Name encoding of the Issuer Name
       of an X.509 certificate authority acceptable to the sender of
       this payload.  This would be included to assist the responder in
       determining how much of the certificate chain would need to be
       sent in response to this request.  If there is no specific
       certificate authority requested, this field SHOULD not be
       included.

   The payload type for the Certificate Request Payload is seven (7).

Top      Up      ToC       Page 36 
3.11 Hash Payload

   The Hash Payload contains data generated by the hash function
   (selected during the SA establishment exchange), over some part of
   the message and/or ISAKMP state.  This payload may be used to verify
   the integrity of the data in an ISAKMP message or for authentication
   of the negotiating entities.  Figure 12 shows the format of the Hash
   Payload.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                           Hash Data                           ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 12:  Hash Payload Format

   The Hash Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Hash Data (variable length) - Data that results from applying the
       hash routine to the ISAKMP message and/or state.

Top      Up      ToC       Page 37 
3.12 Signature Payload

   The Signature Payload contains data generated by the digital
   signature function (selected during the SA establishment exchange),
   over some part of the message and/or ISAKMP state.  This payload is
   used to verify the integrity of the data in the ISAKMP message, and
   may be of use for non-repudiation services.  Figure 13 shows the
   format of the Signature Payload.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                         Signature Data                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 13:  Signature Payload Format

   The Signature Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Signature Data (variable length) - Data that results from
       applying the digital signature function to the ISAKMP message
       and/or state.

   The payload type for the Signature Payload is nine (9).

3.13 Nonce Payload

   The Nonce Payload contains random data used to guarantee liveness
   during an exchange and protect against replay attacks.  Figure 14
   shows the format of the Nonce Payload.  If nonces are used by a
   particular key exchange, the use of the Nonce payload will be
   dictated by the key exchange.  The nonces may be transmitted as part
   of the key exchange data, or as a separate payload.  However, this is
   defined by the key exchange, not by ISAKMP.

Top      Up      ToC       Page 38 
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                            Nonce Data                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 14:  Nonce Payload Format

   The Nonce Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Nonce Data (variable length) - Contains the random data generated
       by the transmitting entity.

   The payload type for the Nonce Payload is ten (10).

3.14 Notification Payload

   The Notification Payload can contain both ISAKMP and DOI-specific
   data and is used to transmit informational data, such as error
   conditions, to an ISAKMP peer.  It is possible to send multiple
   Notification payloads in a single ISAKMP message.  Figure 15 shows
   the format of the Notification Payload.

   Notification which occurs during, or is concerned with, a Phase 1
   negotiation is identified by the Initiator and Responder cookie pair
   in the ISAKMP Header.  The Protocol Identifier, in this case, is
   ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
   Header identifies the ISAKMP SA. If the notification takes place
   prior to the completed exchange of keying information, then the
   notification will be unprotected.

Top      Up      ToC       Page 39 
   Notification which occurs during, or is concerned with, a Phase 2
   negotiation is identified by the Initiator and Responder cookie pair
   in the ISAKMP Header and the Message ID and SPI associated with the
   current negotiation.  One example for this type of notification is to
   indicate why a proposal was rejected.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                Security Parameter Index (SPI)                 ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                       Notification Data                       ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 15:  Notification Payload Format

   The Notification Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Domain of Interpretation (4 octets) - Identifies the DOI (as
       described in Section 2.1) under which this notification is taking
       place.  For ISAKMP this value is zero (0) and for the IPSEC DOI
       it is one (1).  Other DOI's can be defined using the description
       in appendix B.

    o  Protocol-Id (1 octet) - Specifies the protocol identifier for the
       current notification.  Examples might include ISAKMP, IPSEC ESP,
       IPSEC AH, OSPF, TLS, etc.

Top      Up      ToC       Page 40 
    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
       therefore, the SPI Size is irrelevant and MAY be from zero (0) to
       sixteen (16).  If the SPI Size is non-zero, the content of the
       SPI field MUST be ignored.  The Domain of Interpretation (DOI)
       will dictate the SPI Size for other protocols.

    o  Notify Message Type (2 octets) - Specifies the type of
       notification message (see section 3.14.1).  Additional text, if
       specified by the DOI, is placed in the Notification Data field.

    o  SPI (variable length) - Security Parameter Index.  The receiving
       entity's SPI. The use of the SPI field is described in section
       2.4.  The length of this field is determined by the SPI Size
       field and is not necessarily aligned to a 4 octet boundary.

    o  Notification Data (variable length) - Informational or error data
       transmitted in addition to the Notify Message Type.  Values for
       this field are DOI-specific.

   The payload type for the Notification Payload is eleven (11).

3.14.1 Notify Message Types

   Notification information can be error messages specifying why an SA
   could not be established.  It can also be status data that a process
   managing an SA database wishes to communicate with a peer process.
   For example, a secure front end or security gateway may use the
   Notify message to synchronize SA communication.  The table below
   lists the Nofitication messages and their corresponding values.
   Values in the Private Use range are expected to be DOI-specific
   values.

                      NOTIFY MESSAGES - ERROR TYPES

                           Errors               Value
                 INVALID-PAYLOAD-TYPE             1
                 DOI-NOT-SUPPORTED                2
                 SITUATION-NOT-SUPPORTED          3
                 INVALID-COOKIE                   4
                 INVALID-MAJOR-VERSION            5
                 INVALID-MINOR-VERSION            6
                 INVALID-EXCHANGE-TYPE            7
                 INVALID-FLAGS                    8
                 INVALID-MESSAGE-ID               9
                 INVALID-PROTOCOL-ID             10
                 INVALID-SPI                     11

Top      Up      ToC       Page 41 
                 INVALID-TRANSFORM-ID            12
                 ATTRIBUTES-NOT-SUPPORTED        13
                 NO-PROPOSAL-CHOSEN              14
                 BAD-PROPOSAL-SYNTAX             15
                 PAYLOAD-MALFORMED               16
                 INVALID-KEY-INFORMATION         17
                 INVALID-ID-INFORMATION          18
                 INVALID-CERT-ENCODING           19
                 INVALID-CERTIFICATE             20
                 CERT-TYPE-UNSUPPORTED           21
                 INVALID-CERT-AUTHORITY          22
                 INVALID-HASH-INFORMATION        23
                 AUTHENTICATION-FAILED           24
                 INVALID-SIGNATURE               25
                 ADDRESS-NOTIFICATION            26
                 NOTIFY-SA-LIFETIME              27
                 CERTIFICATE-UNAVAILABLE         28
                 UNSUPPORTED-EXCHANGE-TYPE       29
                 UNEQUAL-PAYLOAD-LENGTHS         30
                 RESERVED (Future Use)        31 - 8191
                 Private Use                8192 - 16383



                      NOTIFY MESSAGES - STATUS TYPES
                          Status              Value
                  CONNECTED                   16384
                  RESERVED (Future Use)   16385 - 24575
                  DOI-specific codes     24576 - 32767
                  Private Use            32768 - 40959
                  RESERVED (Future Use)  40960 - 65535

3.15 Delete Payload

   The Delete Payload contains a protocol-specific security association
   identifier that the sender has removed from its security association
   database and is, therefore, no longer valid.  Figure 16 shows the
   format of the Delete Payload.  It is possible to send multiple SPIs
   in a Delete payload, however, each SPI MUST be for the same protocol.
   Mixing of Protocol Identifiers MUST NOT be performed with the Delete
   payload.

   Deletion which is concerned with an ISAKMP SA will contain a
   Protocol-Id of ISAKMP and the SPIs are the initiator and responder
   cookies from the ISAKMP Header.  Deletion which is concerned with a
   Protocol SA, such as ESP or AH, will contain the Protocol-Id of that
   protocol (e.g.  ESP, AH) and the SPI is the sending entity's SPI(s).

Top      Up      ToC       Page 42 
   NOTE: The Delete Payload is not a request for the responder to delete
   an SA, but an advisory from the initiator to the responder.  If the
   responder chooses to ignore the message, the next communication from
   the responder to the initiator, using that security association, will
   fail.  A responder is not expected to acknowledge receipt of a Delete
   payload.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-Id  !   SPI Size    !           # of SPIs           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~               Security Parameter Index(es) (SPI)              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 16:  Delete Payload Format

   The Delete Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Domain of Interpretation (4 octets) - Identifies the DOI (as
       described in Section 2.1) under which this deletion is taking
       place.  For ISAKMP this value is zero (0) and for the IPSEC DOI
       it is one (1).  Other DOI's can be defined using the description
       in appendix B.

    o  Protocol-Id (1 octet) - ISAKMP can establish security
       associations for various protocols, including ISAKMP and IPSEC.
       This field identifies which security association database to
       apply the delete request.

Top      Up      ToC       Page 43 
    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair is the ISAKMP SPI. In this case, the SPI
       Size would be 16 octets for each SPI being deleted.

    o  # of SPIs (2 octets) - The number of SPIs contained in the Delete
       payload.  The size of each SPI is defined by the SPI Size field.

    o  Security Parameter Index(es) (variable length) - Identifies the
       specific security association(s) to delete.  Values for this
       field are DOI and protocol specific.  The length of this field is
       determined by the SPI Size and # of SPIs fields.

   The payload type for the Delete Payload is twelve (12).

3.16 Vendor ID Payload

   The Vendor ID Payload contains a vendor defined constant.  The
   constant is used by vendors to identify and recognize remote
   instances of their implementations.  This mechanism allows a vendor
   to experiment with new features while maintaining backwards
   compatibility.  This is not a general extension facility of ISAKMP.
   Figure 17 shows the format of the Vendor ID Payload.

   The Vendor ID payload is not an announcement from the sender that it
   will send private payload types.  A vendor sending the Vendor ID MUST
   not make any assumptions about private payloads that it may send
   unless a Vendor ID is received as well.  Multiple Vendor ID payloads
   MAY be sent.  An implementation is NOT REQUIRED to understand any
   Vendor ID payloads.  An implementation is NOT REQUIRED to send any
   Vendor ID payload at all.  If a private payload was sent without
   prior agreement to send it, a compliant implementation may reject a
   proposal with a notify message of type INVALID-PAYLOAD-TYPE.

   If a Vendor ID payload is sent, it MUST be sent during the Phase 1
   negotiation.  Reception of a familiar Vendor ID payload in the Phase
   1 negotiation allows an implementation to make use of Private USE
   payload numbers (128-255), described in section 3.1 for vendor
   specific extensions during Phase 2 negotiations.  The definition of
   "familiar" is left to implementations to determine.  Some vendors may
   wish to implement another vendor's extension prior to
   standardization.  However, this practice SHOULD not be widespread and
   vendors should work towards standardization instead.

   The vendor defined constant MUST be unique.  The choice of hash and
   text to hash is left to the vendor to decide.  As an example, vendors
   could generate their vendor id by taking a plain (non-keyed) hash of
   a string containing the product name, and the version of the product.

Top      Up      ToC       Page 44 
   A hash is used instead of a vendor registry to avoid local
   cryptographic policy problems with having a list of "approved"
   products, to keep away from maintaining a list of vendors, and to
   allow classified products to avoid having to appear on any list.  For
   instance:

   "Example Company IPsec.  Version 97.1"

   (not including the quotes) has MD5 hash:
   48544f9b1fe662af98b9b39e50c01a5a, when using MD5file.  Vendors may
   include all of the hash, or just a portion of it, as the payload
   length will bound the data.  There are no security implications of
   this hash, so its choice is arbitrary.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                        Vendor ID (VID)                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 17:  Vendor ID Payload Format

   The Vendor ID Payload fields are defined as follows:

    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  If the current payload is the last
       in the message, then this field will be 0.

    o  RESERVED (1 octet) - Unused, set to 0.

    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header.

    o  Vendor ID (variable length) - Hash of the vendor string plus
       version (as described above).

   The payload type for the Vendor ID Payload is thirteen (13).



(page 44 continued on part 3)

Next RFC Part