tech-invite   World Map     

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

RFC 7401

 
 
 

Host Identity Protocol Version 2 (HIPv2)

Part 3 of 5, p. 38 to 70
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 38 
5.  Packet Formats

5.1.  Payload Format

   All HIP packets start with a fixed header.

    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 Header   | Header Length |0| Packet Type |Version| RES.|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |           Controls            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Sender's Host Identity Tag (HIT)               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Receiver's Host Identity Tag (HIT)              |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                        HIP Parameters                         /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 39 
   The HIP header is logically an IPv6 extension header.  However, this
   document does not describe processing for Next Header values other
   than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value.
   Future documents MAY define behavior for other values.  However,
   current implementations MUST ignore trailing data if an unimplemented
   Next Header value is received.

   The Header Length field contains the combined length of the HIP
   Header and HIP parameters in 8-byte units, excluding the first
   8 bytes.  Since all HIP headers MUST contain the sender's and
   receiver's HIT fields, the minimum value for this field is 4, and
   conversely, the maximum length of the HIP Parameters field is
   (255 * 8) - 32 = 2008 bytes (see Section 5.1.3 regarding HIP
   fragmentation).  Note: this sets an additional limit for sizes of
   parameters included in the Parameters field, independent of the
   individual parameter maximum lengths.

   The Packet Type indicates the HIP packet type.  The individual packet
   types are defined in the relevant sections.  If a HIP host receives a
   HIP packet that contains an unrecognized packet type, it MUST drop
   the packet.

   The HIP Version field is four bits.  The version defined in this
   document is 2.  The version number is expected to be incremented only
   if there are incompatible changes to the protocol.  Most extensions
   can be handled by defining new packet types, new parameter types, or
   new Controls (see Section 5.1.2).

   The following three bits are reserved for future use.  They MUST be
   zero when sent, and they MUST be ignored when handling a received
   packet.

   The two fixed bits in the header are reserved for SHIM6 compatibility
   [RFC5533], Section 5.3.  For implementations adhering (only) to this
   specification, they MUST be set as shown when sending and MUST be
   ignored when receiving.  This is to ensure optimal forward
   compatibility.  Note that for implementations that implement other
   compatible specifications in addition to this specification, the
   corresponding rules may well be different.  For example, an
   implementation that implements both this specification and the SHIM6
   protocol may need to check these bits in order to determine how to
   handle the packet.

   The HIT fields are always 128 bits (16 bytes) long.

Top      Up      ToC       Page 40 
5.1.1.  Checksum

   Since the checksum covers the source and destination addresses in the
   IP header, it MUST be recomputed on HIP-aware NAT devices.

   If IPv6 is used to carry the HIP packet, the pseudo header [RFC2460]
   contains the source and destination IPv6 addresses, HIP packet length
   in the pseudo header Length field, a zero field, and the HIP protocol
   number (see Section 5.1) in the Next Header field.  The Length field
   is in bytes and can be calculated from the HIP Header Length field:

   (HIP Header Length + 1) * 8.

   In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is
   used.  In the pseudo header, the source and destination addresses are
   those used in the IP header, the zero field is obviously zero, the
   protocol is the HIP protocol number (see Section 4), and the length
   is calculated as in the IPv6 case.

5.1.2.  HIP Controls

   The HIP Controls field conveys information about the structure of the
   packet and capabilities of the host.

   The following fields have been defined:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | | | | | | | | | | | | | | | |A|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A - Anonymous:  If this is set, the sender's HI in this packet is
      anonymous, i.e., one not listed in a directory.  Anonymous HIs
      SHOULD NOT be stored.  This control is set in packets using
      anonymous sender HIs.  The peer receiving an anonymous HI in an R1
      or I2 may choose to refuse it.

   The rest of the fields are reserved for future use, and MUST be set
   to zero in sent packets and MUST be ignored in received packets.

5.1.3.  HIP Fragmentation Support

   A HIP implementation MUST support IP fragmentation/reassembly.
   Fragment reassembly MUST be implemented in both IPv4 and IPv6, but
   fragment generation is REQUIRED to be implemented in IPv4 (IPv4
   stacks and networks will usually do this by default) and RECOMMENDED
   to be implemented in IPv6.  In IPv6 networks, the minimum MTU is
   larger, 1280 bytes, than in IPv4 networks.  The larger MTU size is
   usually sufficient for most HIP packets, and therefore fragment

Top      Up      ToC       Page 41 
   generation may not be needed.  If it is expected that a host will
   send HIP packets that are larger than the minimum IPv6 MTU, the
   implementation MUST implement fragment generation even for IPv6.

   In IPv4 networks, HIP packets may encounter low MTUs along their
   routed path.  Since basic HIP, as defined in this document, does not
   provide a mechanism to use multiple IP datagrams for a single HIP
   packet, support for path MTU discovery does not bring any value to
   HIP in IPv4 networks.  HIP-aware NAT devices SHOULD perform IPv4
   reassembly/fragmentation for HIP packets.

   All HIP implementations have to be careful while employing a
   reassembly algorithm so that the algorithm is sufficiently resistant
   to DoS attacks.

   Certificate chains can cause the packet to be fragmented, and
   fragmentation can open implementations to denial-of-service attacks
   [KAU03].  "Hash and URL" schemes as defined in [RFC6253] for HIP
   version 1 may be used to avoid fragmentation and mitigate resulting
   DoS attacks.

5.2.  HIP Parameters

   The HIP parameters carry information that is necessary for
   establishing and maintaining a HIP association.  For example, the
   peer's public keys as well as the signaling for negotiating ciphers
   and payload handling are encapsulated in HIP parameters.  Additional
   information, meaningful for end hosts or middleboxes, may also be
   included in HIP parameters.  The specification of the HIP parameters
   and their mapping to HIP packets and packet types is flexible to
   allow HIP extensions to define new parameters and new protocol
   behavior.

   In HIP packets, HIP parameters are ordered according to their numeric
   type number and encoded in TLV format.

Top      Up      ToC       Page 42 
   The following parameter types are currently defined.

   +------------------------+-------+-----------+----------------------+
   | TLV                    | Type  | Length    | Data                 |
   +------------------------+-------+-----------+----------------------+
   | R1_COUNTER             | 129   | 12        | Puzzle generation    |
   |                        |       |           | counter              |
   |                        |       |           |                      |
   | PUZZLE                 | 257   | 12        | #K and Random #I     |
   |                        |       |           |                      |
   | SOLUTION               | 321   | 20        | #K, Random #I and    |
   |                        |       |           | puzzle solution #J   |
   |                        |       |           |                      |
   | SEQ                    | 385   | 4         | UPDATE packet ID     |
   |                        |       |           | number               |
   |                        |       |           |                      |
   | ACK                    | 449   | variable  | UPDATE packet ID     |
   |                        |       |           | number               |
   |                        |       |           |                      |
   | DH_GROUP_LIST          | 511   | variable  | Ordered list of DH   |
   |                        |       |           | Group IDs supported  |
   |                        |       |           | by a host            |
   |                        |       |           |                      |
   | DIFFIE_HELLMAN         | 513   | variable  | public key           |
   |                        |       |           |                      |
   | HIP_CIPHER             | 579   | variable  | List of HIP          |
   |                        |       |           | encryption           |
   |                        |       |           | algorithms           |
   |                        |       |           |                      |
   | ENCRYPTED              | 641   | variable  | Encrypted part of a  |
   |                        |       |           | HIP packet           |
   |                        |       |           |                      |
   | HOST_ID                | 705   | variable  | Host Identity with   |
   |                        |       |           | Fully Qualified      |
   |                        |       |           | Domain Name (FQDN)   |
   |                        |       |           | or Network Access    |
   |                        |       |           | Identifier (NAI)     |
   |                        |       |           |                      |
   | HIT_SUITE_LIST         | 715   | variable  | Ordered list of the  |
   |                        |       |           | HIT Suites supported |
   |                        |       |           | by the Responder     |
   |                        |       |           |                      |
   | CERT                   | 768   | variable  | HI Certificate; used |
   |                        |       |           | to transfer          |
   |                        |       |           | certificates.        |
   |                        |       |           | Specified in a       |
   |                        |       |           | separate document.   |
   |                        |       |           |                      |

Top      Up      ToC       Page 43 
   | NOTIFICATION           | 832   | variable  | Informational data   |
   |                        |       |           |                      |
   | ECHO_REQUEST_SIGNED    | 897   | variable  | Opaque data to be    |
   |                        |       |           | echoed back; signed  |
   |                        |       |           |                      |
   | ECHO_RESPONSE_SIGNED   | 961   | variable  | Opaque data echoed   |
   |                        |       |           | back by request;     |
   |                        |       |           | signed               |
   |                        |       |           |                      |
   | TRANSPORT_FORMAT_LIST  | 2049  | Ordered   | variable             |
   |                        |       | list of   |                      |
   |                        |       | preferred |                      |
   |                        |       | HIP       |                      |
   |                        |       | transport |                      |
   |                        |       | type      |                      |
   |                        |       | numbers   |                      |
   |                        |       |           |                      |
   | HIP_MAC                | 61505 | variable  | HMAC-based message   |
   |                        |       |           | authentication code, |
   |                        |       |           | with key material    |
   |                        |       |           | from KEYMAT          |
   |                        |       |           |                      |
   | HIP_MAC_2              | 61569 | variable  | HMAC-based message   |
   |                        |       |           | authentication code, |
   |                        |       |           | with key material    |
   |                        |       |           | from KEYMAT.  Unlike |
   |                        |       |           | HIP_MAC, the HOST_ID |
   |                        |       |           | parameter is         |
   |                        |       |           | included in          |
   |                        |       |           | HIP_MAC_2            |
   |                        |       |           | calculation.         |
   |                        |       |           |                      |
   | HIP_SIGNATURE_2        | 61633 | variable  | Signature used in R1 |
   |                        |       |           | packet               |
   |                        |       |           |                      |
   | HIP_SIGNATURE          | 61697 | variable  | Signature of the     |
   |                        |       |           | packet               |
   |                        |       |           |                      |
   | ECHO_REQUEST_UNSIGNED  | 63661 | variable  | Opaque data to be    |
   |                        |       |           | echoed back; after   |
   |                        |       |           | signature            |
   |                        |       |           |                      |
   | ECHO_RESPONSE_UNSIGNED | 63425 | variable  | Opaque data echoed   |
   |                        |       |           | back by request;     |
   |                        |       |           | after signature      |
   +------------------------+-------+-----------+----------------------+

Top      Up      ToC       Page 44 
   As the ordering (from lowest to highest) of HIP parameters is
   strictly enforced (see Section 5.2.1), the parameter type values for
   existing parameters have been spaced to allow for future protocol
   extensions.

   The following parameter type number ranges are defined.

   +---------------+---------------------------------------------------+
   | Type Range    | Purpose                                           |
   +---------------+---------------------------------------------------+
   | 0 -  1023     | Handshake                                         |
   |               |                                                   |
   | 1024 -   2047 | Reserved                                          |
   |               |                                                   |
   | 2048 -   4095 | Parameters related to HIP transport formats       |
   |               |                                                   |
   | 4096 -   8191 | Signed parameters allocated through specification |
   |               | documents                                         |
   |               |                                                   |
   | 8192 -  32767 | Reserved                                          |
   |               |                                                   |
   | 32768 - 49151 | Reserved for Private Use.  Signed parameters.     |
   |               |                                                   |
   | 49152 - 61439 | Reserved                                          |
   |               |                                                   |
   | 61440 - 62463 | Signatures and (signed) MACs                      |
   |               |                                                   |
   | 62464 - 63487 | Parameters that are neither signed nor MACed      |
   |               |                                                   |
   | 63488 - 64511 | Rendezvous and relaying                           |
   |               |                                                   |
   | 64512 - 65023 | Parameters that are neither signed nor MACed      |
   |               |                                                   |
   | 65024 - 65535 | Reserved                                          |
   +---------------+---------------------------------------------------+

   The process for defining new parameters is described in Section 5.2.2
   of this document.

   The range between 32768 (2^15) and 49151 (2^15 + 2^14) is Reserved
   for Private Use.  Types from this range SHOULD be selected in a
   random fashion to reduce the probability of collisions.

5.2.1.  TLV Format

   The TLV-encoded parameters are described in the following
   subsections.  The Type field value also describes the order of these
   fields in the packet.  The parameters MUST be included in the packet

Top      Up      ToC       Page 45 
   so that their types form an increasing order.  If multiple parameters
   with the same type number are in one packet, the parameters with the
   same type MUST be consecutive in the packet.  If the order does not
   follow this rule, the packet is considered to be malformed and it
   MUST be discarded.

   Parameters using type values from 2048 up to 4095 are related to
   transport formats.  Currently, one transport format is defined: the
   ESP transport format [RFC7402].

   All of the encoded TLV parameters have a length (that includes the
   Type and Length fields), which is a multiple of 8 bytes.  When
   needed, padding MUST be added to the end of the parameter so that the
   total length is a multiple of 8 bytes.  This rule ensures proper
   alignment of data.  Any added padding bytes MUST be zeroed by the
   sender, and their values SHOULD NOT be checked by the receiver.

   The Length field indicates the length of the Contents field (in
   bytes).  Consequently, the total length of the TLV parameter
   (including Type, Length, Contents, and Padding) is related to the
   Length field according to the following formula:

   Total Length = 11 + Length - (Length + 3) % 8;

   where % is the modulo operator.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type            |C|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                          Contents                             /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type         Type code for the parameter.  16 bits long, C-bit
                  being part of the Type code.
     C            Critical.  One if this parameter is critical and
                  MUST be recognized by the recipient, zero otherwise.
                  The C-bit is considered to be a part of the Type
                  field.  Consequently, critical parameters are always
                  odd, and non-critical ones have an even value.
     Length       Length of the Contents, in bytes, excluding Type,
                  Length, and Padding
     Contents     Parameter specific, defined by Type
     Padding      Padding, 0-7 bytes, added if needed

Top      Up      ToC       Page 46 
   Critical parameters (indicated by the odd type number value) MUST be
   recognized by the recipient.  If a recipient encounters a critical
   parameter that it does not recognize, it MUST NOT process the packet
   any further.  It MAY send an ICMP or NOTIFY, as defined in
   Section 4.3.

   Non-critical parameters MAY be safely ignored.  If a recipient
   encounters a non-critical parameter that it does not recognize, it
   SHOULD proceed as if the parameter was not present in the received
   packet.

5.2.2.  Defining New Parameters

   Future specifications may define new parameters as needed.  When
   defining new parameters, care must be taken to ensure that the
   parameter type values are appropriate and leave suitable space for
   other future extensions.  One must remember that the parameters MUST
   always be arranged in numerically increasing order by Type code,
   thereby limiting the order of parameters (see Section 5.2.1).

   The following rules MUST be followed when defining new parameters.

   1.  The low-order bit C of the Type code is used to distinguish
       between critical and non-critical parameters.  Hence, even
       parameter type numbers indicate non-critical parameters while odd
       parameter type numbers indicate critical parameters.

   2.  A new parameter MAY be critical only if an old implementation
       that ignored it would cause security problems.  In general, new
       parameters SHOULD be defined as non-critical, and expect a reply
       from the recipient.

   3.  If a system implements a new critical parameter, it MUST provide
       the ability to set the associated feature off, such that the
       critical parameter is not sent at all.  The configuration option
       MUST be well documented.  Implementations operating in a mode
       adhering to this specification MUST disable the sending of new
       critical parameters by default.  In other words, the management
       interface MUST allow vanilla standards-only mode as a default
       configuration setting, and MAY allow new critical payloads to be
       configured on (and off).

   4.  See Section 9 for allocation rules regarding Type codes.

Top      Up      ToC       Page 47 
5.2.3.  R1_COUNTER

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Reserved, 4 bytes                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                R1 generation counter, 8 bytes                 |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           129
     Length         12
     R1 generation
       counter      The current generation of valid puzzles

   The R1_COUNTER parameter contains a 64-bit unsigned integer in
   network byte order, indicating the current generation of valid
   puzzles.  The sender SHOULD increment this counter periodically.  It
   is RECOMMENDED that the counter value is incremented at least as
   often as old PUZZLE values are deprecated so that SOLUTIONs to them
   are no longer accepted.

   Support for the R1_COUNTER parameter is mandatory, although its
   inclusion in the R1 packet is optional.  It SHOULD be included in the
   R1 (in which case it is covered by the signature), and if present in
   the R1, it MUST be echoed (including the Reserved field verbatim) by
   the Initiator in the I2 packet.

Top      Up      ToC       Page 48 
5.2.4.  PUZZLE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  #K, 1 byte   |    Lifetime   |        Opaque, 2 bytes        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Random #I, RHASH_len / 8 bytes           |
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           257
     Length         4 + RHASH_len / 8
     #K             #K is the number of verified bits
     Lifetime       puzzle lifetime 2^(value - 32) seconds
     Opaque         data set by the Responder, indexing the puzzle
     Random #I      random number of size RHASH_len bits

   Random #I is represented as an n-bit integer (where n is RHASH_len),
   and #K and Lifetime as 8-bit integers, all in network byte order.

   The PUZZLE parameter contains the puzzle difficulty #K and an n-bit
   random integer #I.  The Puzzle Lifetime indicates the time during
   which the puzzle solution is valid, and sets a time limit that should
   not be exceeded by the Initiator while it attempts to solve the
   puzzle.  The lifetime is indicated as a power of 2 using the formula
   2^(Lifetime - 32) seconds.  A puzzle MAY be augmented with an
   ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in
   the R1; the contents of the echo request are then echoed back in the
   ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter,
   allowing the Responder to use the included information as a part of
   its puzzle processing.

   The Opaque and Random #I fields are not covered by the
   HIP_SIGNATURE_2 parameter.

Top      Up      ToC       Page 49 
5.2.5.  SOLUTION

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  #K, 1 byte   |   Reserved    |        Opaque, 2 bytes        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Random #I, n bytes                       |
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Puzzle solution #J, RHASH_len / 8 bytes            |
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type                321
     Length              4 + RHASH_len / 4
     #K                  #K is the number of verified bits
     Reserved            zero when sent, ignored when received
     Opaque              copied unmodified from the received PUZZLE
                         parameter
     Random #I           random number of size RHASH_len bits
     Puzzle solution #J  random number of size RHASH_len bits

   Random #I and Random #J are represented as n-bit unsigned integers
   (where n is RHASH_len), and #K as an 8-bit unsigned integer, all in
   network byte order.

   The SOLUTION parameter contains a solution to a puzzle.  It also
   echoes back the random difficulty #K, the Opaque field, and the
   puzzle integer #I.

Top      Up      ToC       Page 50 
5.2.6.  DH_GROUP_LIST

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DH GROUP ID #n|                Padding                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           511
     Length         number of DH Group IDs
     DH GROUP ID    identifies a DH GROUP ID supported by the host.
                    The list of IDs is ordered by preference of the
                    host.  The possible DH Group IDs are defined
                    in the DIFFIE_HELLMAN parameter.  Each DH
                    Group ID is one octet long.

   The DH_GROUP_LIST parameter contains the list of supported DH Group
   IDs of a host.  The Initiator sends the DH_GROUP_LIST in the I1
   packet, and the Responder sends its own list in the signed part of
   the R1 packet.  The DH Group IDs in the DH_GROUP_LIST are listed in
   the order of their preference of the host sending the list.  DH Group
   IDs that are listed first are preferred over the DH Group IDs listed
   later.  The information in the DH_GROUP_LIST allows the Responder to
   select the DH group preferred by itself and supported by the
   Initiator.  Based on the DH_GROUP_LIST in the R1 packet, the
   Initiator can determine if the Responder has selected the best
   possible choice based on the Initiator's and Responder's preferences.
   If the Responder's choice differs from the best choice, the Initiator
   can conclude that there was an attempted downgrade attack (see
   Section 4.1.7).

   When selecting the DH group for the DIFFIE_HELLMAN parameter in the
   R1 packet, the Responder MUST select the first DH Group ID in its
   DH_GROUP_LIST in the R1 packet that is compatible with one of the
   Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet.  The
   Responder MUST NOT select any other DH Group ID that is contained in
   both lists, because then a downgrade attack cannot be detected.

   In general, hosts SHOULD prefer stronger groups over weaker ones if
   the computation overhead is not prohibitively high for the intended
   application.

Top      Up      ToC       Page 51 
5.2.7.  DIFFIE_HELLMAN

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Group ID    |      Public Value Length      | Public Value  /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           513
     Length         length in octets, excluding Type, Length, and
                    Padding
     Group ID       identifies values for p and g as well as the KDF
     Public Value   length of the following Public Value in octets
       Length
     Public Value   the sender's public Diffie-Hellman key

   A single DIFFIE_HELLMAN parameter may be included in selected HIP
   packets based on the DH Group ID selected (Section 5.2.6).  The
   following Group IDs have been defined; values are assigned by this
   document:

    Group                              KDF              Value

    Reserved                                            0
    DEPRECATED                                          1
    DEPRECATED                                          2
    1536-bit MODP group  [RFC3526]     HKDF [RFC5869]   3
    3072-bit MODP group  [RFC3526]     HKDF [RFC5869]   4
    DEPRECATED                                          5
    DEPRECATED                                          6
    NIST P-256 [RFC5903]               HKDF [RFC5869]   7
    NIST P-384 [RFC5903]               HKDF [RFC5869]   8
    NIST P-521 [RFC5903]               HKDF [RFC5869]   9
    SECP160R1  [SECG]                  HKDF [RFC5869]  10
    2048-bit MODP group  [RFC3526]     HKDF [RFC5869]  11

   The MODP Diffie-Hellman groups are defined in [RFC3526].  ECDH
   groups 7-9 are defined in [RFC5903] and [RFC6090].  ECDH group 10
   is covered in Appendix D.  Any ECDH used with HIP MUST have a
   co-factor of 1.

Top      Up      ToC       Page 52 
   The Group ID also defines the key derivation function that is to be
   used for deriving the symmetric keys for the HMAC and symmetric
   encryption from the keying material from the Diffie-Hellman key
   exchange (see Section 6.5).

   A HIP implementation MUST implement Group ID 3.  The 160-bit
   SECP160R1 group can be used when lower security is enough (e.g., web
   surfing) and when the equipment is not powerful enough (e.g., some
   PDAs).  Implementations SHOULD implement Group IDs 4 and 8.

   To avoid unnecessary failures during the base exchange, the rest of
   the groups SHOULD be implemented in hosts where resources are
   adequate.

5.2.8.  HIP_CIPHER

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Cipher ID #1         |          Cipher ID #2         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Cipher ID #n         |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           579
     Length         length in octets, excluding Type, Length, and
                    Padding
     Cipher ID      identifies the cipher algorithm to be used for
                    encrypting the contents of the ENCRYPTED parameter

Top      Up      ToC       Page 53 
   The following Cipher IDs are defined:

        Suite ID           Value

        RESERVED           0
        NULL-ENCRYPT       1     ([RFC2410])
        AES-128-CBC        2     ([RFC3602])
        RESERVED           3     (unused value)
        AES-256-CBC        4     ([RFC3602])

   The sender of a HIP_CIPHER parameter MUST make sure that there are no
   more than six (6) Cipher IDs in one HIP_CIPHER parameter.

   Conversely, a recipient MUST be prepared to handle received transport
   parameters that contain more than six Cipher IDs by accepting the
   first six Cipher IDs and dropping the rest.  The limited number of
   Cipher IDs sets the maximum size of the HIP_CIPHER parameter.  As the
   default configuration, the HIP_CIPHER parameter MUST contain at least
   one of the mandatory Cipher IDs.  There MAY be a configuration option
   that allows the administrator to override this default.

   The Responder lists supported and desired Cipher IDs in order of
   preference in the R1, up to the maximum of six Cipher IDs.  The
   Initiator MUST choose only one of the corresponding Cipher IDs.  This
   Cipher ID will be used for generating the ENCRYPTED parameter.

   Mandatory implementation: AES-128-CBC.  Implementors SHOULD support
   NULL-ENCRYPT for testing/debugging purposes but MUST NOT offer or
   accept this value unless explicitly configured for testing/debugging
   of HIP.

Top      Up      ToC       Page 54 
5.2.9.  HOST_ID

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          HI Length            |DI-Type|      DI Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Algorithm            |         Host Identity         /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |       Domain Identifier       /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type               705
     Length             length in octets, excluding Type, Length, and
                        Padding
     HI Length          length of the Host Identity in octets
     DI-Type            type of the following Domain Identifier field
     DI Length          length of the Domain Identifier field in octets
     Algorithm          index to the employed algorithm
     Host Identity      actual Host Identity
     Domain Identifier  the identifier of the sender

   The following DI-Types have been defined:

         Type                    Value

         none included           0
         FQDN                    1
         NAI                     2

         FQDN            Fully Qualified Domain Name, in binary format
         NAI             Network Access Identifier

   The format for the FQDN is defined in RFC 1035 [RFC1035],
   Section 3.1.  The format for the NAI is defined in [RFC4282].

   A host MAY optionally associate the Host Identity with a single
   Domain Identifier in the HOST_ID parameter.  If there is no Domain
   Identifier, i.e., the DI-Type field is zero, the DI Length field is
   set to zero as well.

Top      Up      ToC       Page 55 
   The following HI Algorithms have been defined:

        Algorithm profiles   Values

        RESERVED             0
        DSA                  3 [FIPS.186-4.2013]  (RECOMMENDED)
        RSA                  5 [RFC3447]          (REQUIRED)
        ECDSA                7 [RFC4754]          (REQUIRED)
        ECDSA_LOW            9 [SECG]             (RECOMMENDED)

   For DSA, RSA, and ECDSA key types, profiles containing at least
   112 bits of security strength (as defined by [NIST.800-131A.2011])
   should be used.  For RSA signature padding, the Probabilistic
   Signature Scheme (PSS) method of padding [RFC3447] MUST be used.

   The Host Identity is derived from the DNSKEY format for RSA and DSA.
   For these, the Public Key field of the RDATA part from RFC 4034
   [RFC4034] is used.  For Elliptic Curve Cryptography (ECC), we
   distinguish two different profiles: ECDSA and ECDSA_LOW.  ECC
   contains curves approved by NIST and defined in RFC 4754 [RFC4754].
   ECDSA_LOW is defined for devices with low computational capabilities
   and uses shorter curves from the Standards for Efficient Cryptography
   Group [SECG].  Any ECDSA used with HIP MUST have a co-factor of 1.

   For ECDSA and ECDSA_LOW, Host Identities are represented by the
   following fields:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          ECC Curve            |                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                         Public Key                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ECC Curve     Curve label
     Public Key    Represented in octet-string format [RFC6090]

   For hosts that implement ECDSA as the algorithm, the following ECC
   curves are required:

        Algorithm    Curve            Values

        ECDSA        RESERVED         0
        ECDSA        NIST P-256       1 [RFC4754]
        ECDSA        NIST P-384       2 [RFC4754]

Top      Up      ToC       Page 56 
   For hosts that implement the ECDSA_LOW algorithm profile, the
   following curve is required:

        Algorithm    Curve            Values

        ECDSA_LOW    RESERVED         0
        ECDSA_LOW    SECP160R1        1 [SECG]

5.2.10.  HIT_SUITE_LIST

   The HIT_SUITE_LIST parameter contains a list of the supported HIT
   Suite IDs of the Responder.  The Responder sends the HIT_SUITE_LIST
   in the signed part of the R1 packet.  Based on the HIT_SUITE_LIST,
   the Initiator can determine which source HIT Suite IDs are supported
   by the Responder.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ID #1     |     ID #2     |     ID #3     |     ID #4     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ID #n     |                Padding                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           715
     Length         number of HIT Suite IDs
     ID             identifies a HIT Suite ID supported by the host.
                    The list of IDs is ordered by preference of the
                    host.  Each HIT Suite ID is one octet long.  The
                    four higher-order bits of the ID field correspond
                    to the HIT Suite ID in the ORCHID OGA ID field.  The
                    four lower-order bits are reserved and set to 0
                    by the sender.  The reception of an ID with the
                    four lower-order bits not set to 0 SHOULD be
                    considered as an error that MAY result in a
                    NOTIFICATION of type UNSUPPORTED_HIT_SUITE.

   The HIT Suite ID indexes a HIT Suite.  HIT Suites are composed of
   signature algorithms as defined in Section 5.2.9, and hash functions.

   The ID field in the HIT_SUITE_LIST is defined as an eight-bit field,
   as opposed to the four-bit HIT Suite ID and OGA ID field in the
   ORCHID.  This difference is a measure to accommodate larger HIT Suite
   IDs if the 16 available values prove insufficient.  In that case, one
   of the 16 values, zero, will be used to indicate that four additional
   bits of the ORCHID will be used to encode the HIT Suite ID.  Hence,

Top      Up      ToC       Page 57 
   the current four-bit HIT Suite IDs only use the four higher-order
   bits in the ID field.  Future documents may define the use of the
   four lower-order bits in the ID field.

   The following HIT Suite IDs are defined, and the relationship between
   the four-bit ID value used in the OGA ID field and the eight-bit
   encoding within the HIT_SUITE_LIST ID field is clarified:

        HIT Suite       Four-bit ID    Eight-bit encoding

        RESERVED            0             0x00
        RSA,DSA/SHA-256     1             0x10           (REQUIRED)
        ECDSA/SHA-384       2             0x20           (RECOMMENDED)
        ECDSA_LOW/SHA-1     3             0x30           (RECOMMENDED)

   The following table provides more detail on the above HIT Suite
   combinations.  The input for each generation algorithm is the
   encoding of the HI as defined in Section 3.2.  The output is 96 bits
   long and is directly used in the ORCHID.

   +-------+----------+--------------+------------+--------------------+
   | Index | Hash     | HMAC         | Signature  | Description        |
   |       | function |              | algorithm  |                    |
   |       |          |              | family     |                    |
   +-------+----------+--------------+------------+--------------------+
   |     0 |          |              |            | Reserved           |
   |       |          |              |            |                    |
   |     1 | SHA-256  | HMAC-SHA-256 | RSA, DSA   | RSA or DSA HI      |
   |       |          |              |            | hashed with        |
   |       |          |              |            | SHA-256, truncated |
   |       |          |              |            | to 96 bits         |
   |       |          |              |            |                    |
   |     2 | SHA-384  | HMAC-SHA-384 | ECDSA      | ECDSA HI hashed    |
   |       |          |              |            | with SHA-384,      |
   |       |          |              |            | truncated to 96    |
   |       |          |              |            | bits               |
   |       |          |              |            |                    |
   |     3 | SHA-1    | HMAC-SHA-1   | ECDSA_LOW  | ECDSA_LOW HI       |
   |       |          |              |            | hashed with SHA-1, |
   |       |          |              |            | truncated to 96    |
   |       |          |              |            | bits               |
   +-------+----------+--------------+------------+--------------------+

                           Table 10: HIT Suites

Top      Up      ToC       Page 58 
   The hash of the Responder as defined in the HIT Suite determines the
   HMAC to be used for the RHASH function.  The HMACs currently defined
   here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and
   HMAC-SHA-1 [RFC2404].

5.2.11.  TRANSPORT_FORMAT_LIST

   The TRANSPORT_FORMAT_LIST parameter contains a list of the supported
   HIP transport formats (TFs) of the Responder.  The Responder sends
   the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet.  Based
   on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable
   transport format and includes the respective HIP transport format
   parameter in its response packet.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          TF type #1           |           TF type #2          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /          TF type #n           |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           2049
     Length         2x number of TF types
     TF Type        identifies a transport format (TF) type supported
                    by the host.  The TF type numbers correspond to
                    the HIP parameter type numbers of the respective
                    transport format parameters.  The list of TF types
                    is ordered by preference of the sender.

   The TF type numbers index the respective HIP parameters for the
   transport formats in the type number range between 2050 and 4095.
   The parameters and their use are defined in separate documents.
   Currently, the only transport format defined is IPsec ESP [RFC7402].

   For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST
   parameter MUST include the respective transport format parameter in
   the HIP packet.  The receiver MUST ignore the TF type in the
   TRANSPORT_FORMAT_LIST if no matching transport format parameter is
   present in the packet.

Top      Up      ToC       Page 59 
5.2.12.  HIP_MAC

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             HMAC                              |
     /                                                               /
     /                               +-------------------------------+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           61505
     Length         length in octets, excluding Type, Length, and
                    Padding
     HMAC           HMAC computed over the HIP packet, excluding the
                    HIP_MAC parameter and any following parameters,
                    such as HIP_SIGNATURE, HIP_SIGNATURE_2,
                    ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED.
                    The Checksum field MUST be set to zero, and the
                    HIP header length in the HIP common header MUST be
                    calculated not to cover any excluded parameters
                    when the HMAC is calculated.  The size of the
                    HMAC is the natural size of the hash computation
                    output depending on the used hash function.

   The HMAC uses RHASH as the hash algorithm.  The calculation and
   verification process is presented in Section 6.4.1.

5.2.13.  HIP_MAC_2

   HIP_MAC_2 is a MAC of the packet and the HI of the sender in the form
   of a HOST_ID parameter when that parameter is not actually included
   in the packet.  The parameter structure is the same as the structure
   shown in Section 5.2.12.  The fields are as follows:

     Type           61569
     Length         length in octets, excluding Type, Length, and
                    Padding
     HMAC           HMAC computed over the HIP packet, excluding the
                    HIP_MAC_2 parameter and any following parameters
                    such as HIP_SIGNATURE, HIP_SIGNATURE_2,
                    ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED,
                    and including an additional sender's HOST_ID
                    parameter during the HMAC calculation.  The
                    Checksum field MUST be set to zero, and the HIP

Top      Up      ToC       Page 60 
                    header length in the HIP common header MUST be
                    calculated not to cover any excluded parameters
                    when the HMAC is calculated.  The size of the
                    HMAC is the natural size of the hash computation
                    output depending on the used hash function.

   The HMAC uses RHASH as the hash algorithm.  The calculation and
   verification process is presented in Section 6.4.1.

5.2.14.  HIP_SIGNATURE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    SIG alg                    |            Signature          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           61697
     Length         length in octets, excluding Type, Length, and
                    Padding
     SIG alg        signature algorithm
     Signature      the signature is calculated over the HIP packet,
                    excluding the HIP_SIGNATURE parameter and any
                    parameters that follow the HIP_SIGNATURE
                    parameter.  When the signature is calculated, the
                    Checksum field MUST be set to zero, and the HIP
                    header length in the HIP common header MUST be
                    calculated only up to the beginning of the
                    HIP_SIGNATURE parameter.

   The signature algorithms are defined in Section 5.2.9.  The signature
   in the Signature field is encoded using the method depending on the
   signature algorithm (e.g., according to [RFC3110] in the case of RSA/
   SHA-1, [RFC5702] in the case of RSA/SHA-256, [RFC2536] in the case of
   DSA, or [RFC6090] in the case of ECDSA).

   HIP_SIGNATURE calculation and verification follow the process defined
   in Section 6.4.2.

Top      Up      ToC       Page 61 
5.2.15.  HIP_SIGNATURE_2

   HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet to
   allow R1 pre-creation.  The parameter structure is the same as the
   structure shown in Section 5.2.14.  The fields are as follows:

     Type           61633
     Length         length in octets, excluding Type, Length, and
                    Padding
     SIG alg        signature algorithm
     Signature      Within the R1 packet that contains the
                    HIP_SIGNATURE_2 parameter, the Initiator's HIT, the
                    Checksum field, and the Opaque and Random #I fields
                    in the PUZZLE parameter MUST be set to zero while
                    computing the HIP_SIGNATURE_2 signature.  Further,
                    the HIP packet length in the HIP header MUST be
                    adjusted as if the HIP_SIGNATURE_2 was not in the
                    packet during the signature calculation, i.e., the
                    HIP packet length points to the beginning of
                    the HIP_SIGNATURE_2 parameter during signing and
                    verification.

   Zeroing the Initiator's HIT makes it possible to create R1 packets
   beforehand, to minimize the effects of possible DoS attacks.  Zeroing
   the Random #I and Opaque fields within the PUZZLE parameter allows
   these fields to be populated dynamically on precomputed R1s.

   Signature calculation and verification follow the process defined in
   Section 6.4.2.

5.2.16.  SEQ

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Update ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type            385
     Length          4
     Update ID       32-bit sequence number

   The Update ID is an unsigned number in network byte order,
   initialized by a host to zero upon moving to ESTABLISHED state.  The
   Update ID has scope within a single HIP association, and not across

Top      Up      ToC       Page 62 
   multiple associations or multiple hosts.  The Update ID is
   incremented by one before each new UPDATE that is sent by the host;
   the first UPDATE packet originated by a host has an Update ID of 0.

5.2.17.  ACK

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       peer Update ID 1                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       peer Update ID n                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type             449
     Length           length in octets, excluding Type and Length
     peer Update ID   32-bit sequence number corresponding to the
                      Update ID being ACKed

   The ACK parameter includes one or more Update IDs that have been
   received from the peer.  The number of peer Update IDs can be
   inferred from the length by dividing it by 4.

5.2.18.  ENCRYPTED

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              IV                               /
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                        Encrypted data                         /
     /                                                               /
     /                               +-------------------------------+
     /                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type           641
     Length         length in octets, excluding Type, Length, and
                    Padding
     Reserved       zero when sent, ignored when received

Top      Up      ToC       Page 63 
     IV             Initialization vector, if needed, otherwise
                    nonexistent.  The length of the IV is inferred from
                    the HIP_CIPHER.
     Encrypted      The data is encrypted using the encryption algorithm
       data         defined in the HIP_CIPHER parameter.

   The ENCRYPTED parameter encapsulates other parameters, the encrypted
   data, which holds one or more HIP parameters in block encrypted form.

   Consequently, the first fields in the encapsulated parameter(s) are
   Type and Length of the first such parameter, allowing the contents to
   be easily parsed after decryption.

   The field labeled "Encrypted data" consists of the output of one or
   more HIP parameters concatenated together that have been passed
   through an encryption algorithm.  Each of these inner parameters is
   padded according to the rules of Section 5.2.1 for padding individual
   parameters.  As a result, the concatenated parameters will be a block
   of data that is 8-byte aligned.

   Some encryption algorithms require that the data to be encrypted must
   be a multiple of the cipher algorithm block size.  In this case, the
   above block of data MUST include additional padding, as specified by
   the encryption algorithm.  The size of the extra padding is selected
   so that the length of the unencrypted data block is a multiple of the
   cipher block size.  The encryption algorithm may specify padding
   bytes other than zero; for example, AES [FIPS.197.2001] uses the
   PKCS5 padding scheme (see Section 6.1.1 of [RFC2898]) where the
   remaining n bytes to fill the block each have the value of n.  This
   yields an "unencrypted data" block that is transformed to an
   "encrypted data" block by the cipher suite.  This extra padding added
   to the set of parameters to satisfy the cipher block alignment rules
   is not counted in HIP TLV Length fields, and this extra padding
   should be removed by the cipher suite upon decryption.

   Note that the length of the cipher suite output may be smaller or
   larger than the length of the set of parameters to be encrypted,
   since the encryption process may compress the data or add additional
   padding to the data.

   Once this encryption process is completed, the Encrypted data field
   is ready for inclusion in the parameter.  If necessary, additional
   Padding for 8-byte alignment is then added according to the rules of
   Section 5.2.1.

Top      Up      ToC       Page 64 
5.2.19.  NOTIFICATION

   The NOTIFICATION parameter is used to transmit informational data,
   such as error conditions and state transitions, to a HIP peer.  A
   NOTIFICATION parameter may appear in NOTIFY packets.  The use of the
   NOTIFICATION parameter in other packet types is for further study.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Reserved             |      Notify Message Type      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                   Notification Data                           /
     /                                               +---------------+
     /                                               |     Padding   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type             832
     Length           length in octets, excluding Type, Length, and
                      Padding
     Reserved         zero when sent, ignored when received
     Notify Message   specifies the type of notification
       Type
     Notification     informational or error data transmitted in
       Data           addition to the Notify Message Type.  Values
                      for this field are type specific (see below).

   Notification information can be error messages specifying why a HIP
   Security Association could not be established.  It can also be status
   data that a HIP implementation wishes to communicate with a peer
   process.  The table below lists the notification messages and their
   Notify Message Types.  HIP packets MAY contain multiple NOTIFICATION
   parameters if several problems exist or several independent pieces of
   information must be transmitted.

   To avoid certain types of attacks, a Responder SHOULD avoid sending a
   NOTIFICATION to any host with which it has not successfully verified
   a puzzle solution.

   Notify Message Types in the range 0-16383 are intended for reporting
   errors, and those in the range 16384-65535 are for other status
   information.  An implementation that receives a NOTIFY packet with a
   Notify Message Type that indicates an error in response to a request

Top      Up      ToC       Page 65 
   packet (e.g., I1, I2, UPDATE) SHOULD assume that the corresponding
   request has failed entirely.  Unrecognized error types MUST be
   ignored, except that they SHOULD be logged.

   As currently defined, Notify Message Type values 1-10 are used for
   informing about errors in packet structures, and values 11-20 for
   informing about problems in parameters.

   Notification Data in NOTIFICATION parameters where the Notify Message
   Type is in the status range MUST be ignored if not recognized.

     Notify Message Types - Errors             Value
     -----------------------------             -----

     UNSUPPORTED_CRITICAL_PARAMETER_TYPE        1

       Sent if the parameter type has the "critical" bit set and the
       parameter type is not recognized.  Notification Data contains the
       two-octet parameter type.

     INVALID_SYNTAX                             7

       Indicates that the HIP message received was invalid because some
       type, length, or value was out of range or because the request
       was otherwise malformed.  To avoid a denial-of-service
       attack using forged messages, this status may only be returned
       for packets whose HIP_MAC (if present) and SIGNATURE have been
       verified.  This status MUST be sent in response to any error not
       covered by one of the other status types and SHOULD NOT contain
       details, to avoid leaking information to someone probing a node.
       To aid debugging, more detailed error information SHOULD be
       written to a console or log.

     NO_DH_PROPOSAL_CHOSEN                     14

       None of the proposed Group IDs were acceptable.

     INVALID_DH_CHOSEN                         15

       The DH Group ID field does not correspond to one offered
       by the Responder.

     NO_HIP_PROPOSAL_CHOSEN                    16

       None of the proposed HIT Suites or HIP Encryption Algorithms were
       acceptable.

Top      Up      ToC       Page 66 
     INVALID_HIP_CIPHER_CHOSEN                 17

       The HIP_CIPHER Crypto ID does not correspond to one offered by
       the Responder.

     UNSUPPORTED_HIT_SUITE                     20

       Sent in response to an I1 or R1 packet for which the HIT Suite
       is not supported.

     AUTHENTICATION_FAILED                     24

       Sent in response to a HIP signature failure, except when
       the signature verification fails in a NOTIFY message.

     CHECKSUM_FAILED                           26

       Sent in response to a HIP checksum failure.

     HIP_MAC_FAILED                            28

       Sent in response to a HIP HMAC failure.

     ENCRYPTION_FAILED                         32

       The Responder could not successfully decrypt the
       ENCRYPTED parameter.

     INVALID_HIT                               40

       Sent in response to a failure to validate the peer's
       HIT from the corresponding HI.

     BLOCKED_BY_POLICY                         42

       The Responder is unwilling to set up an association
       for some policy reason (e.g., the received HIT is NULL
       and the policy does not allow opportunistic mode).

     RESPONDER_BUSY_PLEASE_RETRY               44

       The Responder is unwilling to set up an association, as it is
       suffering under some kind of overload and has chosen to shed load
       by rejecting the Initiator's request.  The Initiator may retry;
       however, the Initiator MUST find another (different) puzzle
       solution for any such retries.  Note that the Initiator may need
       to obtain a new puzzle with a new I1/R1 exchange.

Top      Up      ToC       Page 67 
     Notify Message Types - Status            Value
     -----------------------------            -----

     I2_ACKNOWLEDGEMENT                       16384

       The Responder has an I2 packet from the Initiator but had to
       queue the I2 packet for processing.  The puzzle was correctly
       solved, and the Responder is willing to set up an association but
       currently has a number of I2 packets in the processing queue.
       The R2 packet is sent after the I2 packet was processed.

5.2.20.  ECHO_REQUEST_SIGNED

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Opaque data (variable length)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          897
     Length        length of the opaque data in octets
     Opaque data   opaque data, supposed to be meaningful only to
                   the node that sends ECHO_REQUEST_SIGNED and
                   receives a corresponding ECHO_RESPONSE_SIGNED or
                   ECHO_RESPONSE_UNSIGNED

   The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data
   that the sender wants to get echoed back in the corresponding reply
   packet.

   The ECHO_REQUEST_SIGNED and corresponding echo response parameters
   MAY be used for any purpose where a node wants to carry some state in
   a request packet and get it back in a response packet.  The
   ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE.  A HIP
   packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY
   contain multiple ECHO_REQUEST_UNSIGNED parameters.  The
   ECHO_REQUEST_SIGNED parameter MUST be responded to with an
   ECHO_RESPONSE_SIGNED.

Top      Up      ToC       Page 68 
5.2.21.  ECHO_REQUEST_UNSIGNED

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Opaque data (variable length)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          63661
     Length        length of the opaque data in octets
     Opaque data   opaque data, supposed to be meaningful only to
                   the node that sends ECHO_REQUEST_UNSIGNED and
                   receives a corresponding ECHO_RESPONSE_UNSIGNED

   The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data
   that the sender wants to get echoed back in the corresponding reply
   packet.

   The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters
   MAY be used for any purpose where a node wants to carry some state in
   a request packet and get it back in a response packet.  The
   ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE.  A
   HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
   It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters
   in HIP packets passing by.  The creator of the ECHO_REQUEST_UNSIGNED
   (end host or middlebox) has to create the Opaque field so that it can
   later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED
   parameter.

   The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an
   ECHO_RESPONSE_UNSIGNED parameter.

Top      Up      ToC       Page 69 
5.2.22.  ECHO_RESPONSE_SIGNED

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Opaque data (variable length)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          961
     Length        length of the opaque data in octets
     Opaque data   opaque data, copied unmodified from the
                   ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED
                   parameter that triggered this response

   The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data
   that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back.
   The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED
   parameter.

   The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be
   used for any purpose where a node wants to carry some state in a
   request packet and get it back in a response packet.  The
   ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE.

5.2.23.  ECHO_RESPONSE_UNSIGNED

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Opaque data (variable length)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          63425
     Length        length of the opaque data in octets
     Opaque data   opaque data, copied unmodified from the
                   ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED
                   parameter that triggered this response

   The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data
   that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED
   wants to get echoed back.  The opaque data is copied unmodified from
   the corresponding echo request parameter.

Top      Up      ToC       Page 70 
   The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used
   for any purpose where a node wants to carry some state in a request
   packet and get it back in a response packet.  The
   ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE.



(page 70 continued on part 4)

Next RFC Part