recent changes requested on the list

[James Luciani <[e-mail]>]

Folks,

  In the last couple of weeks, a number of requests for various changes to 
NHRP have been made.  These requests are a result of a number of 
folks desiring alignment with other protocol efforts:  e.g., MPOA, RFC1577+, 
and MARS.  There have also been a number of requests which were motivated by 
the dropping of the IP encap and dropping of server mode.  In an attempt to 
get a handle on the implications of these requests, I wrote text for the packet 
format section of NHRP which reflects these requests.  The text I generated 
is given below.

  The changes reflected below which were not in my previous note on 
request, reply, and register packet formats are:

   1) Protocol ID is now 6 bytes
   2) There is only one "best" next hop entry in the reply but
   3) There is an Extension for other Next Hop entries (Section 5.7.9)
   4) Expounded on the meaning of the error messages
   5) Packet length is part of the Fixed Part. 
   6) Protocol Length field is added which tells how long the internetwork layer
      protocol address length is.
   7) Removed the "S" bit and kept the "B" bit kinda as per Yakov's suggestion.  
      I say "kinda" as I took a bit of a liberty and removed the S bit and
      renamed the B bit to S since S is for 'S'table. If you want to do a 
      global-replace-regexp go for it :-)
   8) Added the new "S" bit to the Next Hop entry since each next hop entry
      would need to be identified as stable.  As it was, there was only one
      bit in the reply for all next hop entries.
   9) The addition of source NBMA Address information so that NHRP entities may
      exactly which interface sent a give packet.

  Things I did not address below are:
   A) EDFG Origin Flag requested by Eric Grey
   B) Yakov's and Bruce's request to add internetwork layer address length 
      fields on a per address basis rather than one per packet.
   C) Russel's request to add a destination address mask field to the
      IP-specific part of the Purge packet.

Since I am writing this, I get first shot a commenting on A, B, C :-)

I have no conceptual problem with "A" but I am not completely clear why
this is needed but perhaps I should just read the updated MPOA doc.

I'd like more info on 'B'.

On 'C', I'd prefer to just allow the destination prefix extension to be included
in the purge packet (which it currently is not) and I would very much prefer
to see this be optional and not a requirement.  I do see value in it though.

===============================================================================
5. Packet Formats

   This section describes the format of NHRP packets.

   An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
   Extensions Part.  The Fixed Part is common to all NHRP packet types.
   The Mandatory Part MUST be present, but varies depending on packet
   type.  The Extensions Part also varies depending on packet type, and
   need not be present.

   The length of the Fixed Part is fixed at 12 octets.  The length of the
   Mandatory Part is carried in the Fixed Part.  The length of the
   Extensions Part is implied by the total packet length (datagram total
   length minus link layer encapsulation length minus NHRP fixed part
   length minus NHRP mandatory part length).

   NHRP packets are carried in LLC/SNAP encapsulated packets.  NHSs may
   increase the size of an NHRP packet as a result of extension
   processing.

   Fields marked "unused" MUST be set to zero on transmission, and
   ignored on receipt.

   Most packet types have both internetwork layer protocol-independent
   fields and protocol-specific fields.  The protocol-independent fields
   always come first in the packet, and the Protocol ID field qualifies
   the format of the protocol-specific fields.  The protocol-specific
   fields defined in this document are for IPv4 only;  formats of
   protocol-specific fields for other protocols are for further study.

   The protocol ID field in general will contain the Ethertype value for
   the protocol (see [6]).  For protocols that do not have an assigned
   Ethertype, this field will in general contain the Network Layer

   Protocol Identifier (NLPID, [5]) value for the protocol (this is
   guaranteed to not cause collisions since the NLPID cannot be greater
   than 255 decimal, and the Ethertype cannot be less than 1500
   decimal).


5.1 NHRP Fixed Header

   The NHRP Fixed Header is present in all NHRP packets.  It contains
   the basic information needed to parse the rest of the 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |   Hop Count   |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Unused     |        Packet Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mandatory Part Length      |          Unused               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Version
     The NHRP version number.  Currently this value is 1.

   Hop Count
     The Hop count indicates the maximum number of NHSs that an NHRP
     packet is allowed to traverse before being discarded.

   Checksum
     The standard IP checksum over the entire NHRP packet (starting with
     the fixed header).  If only the hop count field is changed, the
     checksum is adjusted without full recomputation.  The checksum is
     completely recomputed when other header fields are changed.

   Packet Length
     This is the length of the NHRP packet as a whole.

   Type
     The NHRP packet type: Request, Response, Register, Purge, or Error
     Indication (see below).

   Mandatory Part Length
     The length in octets of the Mandatory Part.  This length does not
     include the Fixed Header.


5.2 NHRP Request

   The NHRP Request packet has a Type code of 1.  The NHRP Request packet
   is used to register a client with the clients NHS by making a request for
   itself.  This is done by setting the source address equal the destination 
   address (which also equals client address) and the reply received serves 
   as the acknowledgment for the registration.

   The Mandatory Part has the following format:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Q|A|P|  Unused | Proto Length  |         Protocol ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Protocol ID (Cntd)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Request ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               (IPv4-Specific)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IP address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source IP address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Source Address Holding Time  |  Source Address Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Unused     |  NBMA Length  | Source NBMA Address (variable)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Q
     Set if the Requester is a router;  clear if the requester is a
     host.

   A
     A response to an NHRP request may contain cached information.  If
     an authoritative answer is desired, then this bit ("Authoritative")
     should be set.  If non-authoritative (cached) information is
     acceptable, this bit should be clear.

   P
     Unused (zero on transmit)


   Proto Length
     This is the length of the internetwork layer protocol address.

   Protocol ID
     Specifies the internetwork layer protocol for which we are
p     obtaining routing information.  This value also qualifies the
     structure of the remainder of the Mandatory Part.  For IPv4, the
     Protocol ID is hexadecimal 800 (decimal 2048).  Protocol ID values
     for other internetwork layer protocols are for future study.

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Request and its associated Reply, and any subsequent Purge.  This
     value can be used by the source to aid in matching requests with
     replies.  This value could also be sent across a virtual circuit
     (in SVC environments) to aid in matching NHRP transactions with
     virtual circuits (this use is for further study).

     The value is taken from a 32 bit counter that is incremented each
     time a new NHRP request is transmitted.  The same value MUST be
     used when sending another request for the same destination when a
     previous request is still active or pending, i.e., when
     retransmitting a request because a reply was not received, or when
     refreshing an existing entry to avoid holding timer expiration.  A
     new value MUST be used when sending a request when no cache entry
     is present, or a previous cache entry was deleted for any reason.

   Destination and Source IP Addresses
     Respectively, these are the IP addresses of the station for which
     the NBMA next hop is desired, and the NHRP request initiator.

   Source Address Holding Time
     The Source Address Holding Time field specifies the number of seconds for 
     which the source NBMA information is considered to be valid.  Cached
     information SHALL be discarded when the holding time expires.

   Source Address Type
     The Source Address Type field specifies the type of NBMA address
     (qualifying the NBMA address).  Possible address types are listed
     in [6].

   NBMA Length
     The NBMA Length field is the length of the NBMA address of the
     source station in bits.  

   Source NBMA Address
     The Source NBMA Address field is the address of the source station 
     that initiated the request.  It is zero-filled to the nearest 
     32-bit boundary.

   The Request packet may be used to register a station's IP and NBMA addresses
   with its neighboring NHSs. This is done by specifying both the source and 
   destination address to be the client's address.  Registering a clients
   address with its NHS allows the amount of static configuration
   information to be reduced;  the NHSs need not be configured with the
   identities of all of the stations that they serve.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this is the case, the NHS MUST
   reply with an Error Indication of type Can't Serve This Address.

   If an NHS cannot serve a station due to a lack of resources, the NHS
   MUST reply with an Error Indication of type Registration Overflow.

   In order to keep the registration entry from being discarded, the
   station MUST re-register often enough to refresh the entry.  It is
   recommended that the re-registration be sent at an interval equal
   to one-third of the Holding Time specified therein.

5.3 NHRP Reply

   The NHRP Reply packet has a type code of 2.  The NHRP Reply packet also 
   serves to acknowledge the registration of a client with its server.
   That occurs when the request received has the source address equal
   to the destination address.

   The Mandatory Part has the following format:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Q|A|P|  Unused | Proto Length  |         Protocol ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Protocol ID (Cntd)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Request ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               (IPv4-Specific)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination IP address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source IP address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Source Address Holding Time  |  Source Address Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Unused     |  NBMA Length  | Source NBMA Address (variable)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Next-hop IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Holding Time          |         Address Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|  Preference |  NBMA Length  | NBMA Address (variable length)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Q
     Copied from the NHRP Request.  Set if the Requester is a router;
     clear if the requester is a host.

   A
     Set if next hop in the reply is authoritative;  clear if the reply 
     is non-authoritative.

   P
     Set if the reply is positive;  clear if the reply is negative.


   An NHS is not allowed to reply to an NHRP request for authoritative
   information with cached information, but may do so for an NHRP
   Request which indicates a request for non-authoritative information.
   An NHS may reply to an NHRP request for non-authoritative information
   with authoritative information.


   Proto Length
     This is the length of the internetwork layer protocol address.

   Protocol ID
     Specifies the internetwork layer protocol for which we are
     obtaining routing information.  This value also qualifies the
     structure of the remainder of the Mandatory Part.  For IPv4, the
     Protocol ID is hexadecimal 800 (decimal 2048).  Protocol ID values
     for other internetwork layer protocols are for future study.

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Request and its associated Reply, and any subsequent Purge.  This
     value can be used by the source to aid in matching requests with
     replies.  This value could also be sent across a virtual circuit
     (in SVC environments) to aid in matching NHRP transactions with
     virtual circuits (this use is for further study).

     The value is taken from a 32 bit counter that is incremented each
     time a new NHRP request is transmitted.  The same value MUST be
     used when sending another request for the same destination when a
     previous request is still active or pending, i.e., when
     retransmitting a request because a reply was not received, or when
     refreshing an existing entry to avoid holding timer expiration.  A
     new value MUST be used when sending a request when no cache entry
     is present, or a previous cache entry was deleted for any reason.

   Destination and Source IP Addresses
     Respectively, these are the IP addresses of the station for which
     the NBMA next hop is desired, and the NHRP request initiator.

   Source Address Holding Time
     The Source Address Holding Time field specifies the number of seconds for 
     which the source NBMA information is considered to be valid.  Cached
     information SHALL be discarded when the holding time expires.

   Source Address Type
     The Source Address Type field specifies the type of NBMA address
     (qualifying the NBMA address).  Possible address types are listed
     in [6].

   NBMA Length
     The NBMA Length field is the length of the NBMA address of the
     source station in bits.  

   Source NBMA Address
     The Source NBMA Address field is the address of the source station 
     that initiated the request.  It is zero-filled to the nearest 
     32-bit boundary.

   Next-hop entry
     A Next-hop entry consists of the following fields: a 32-bit Next-
     hop IP Address, a 16-bit Holding Time, a S bit, a 7-bit Preference, 
     an 8-bit Address Type, an 8-bit NBMA Length, and an NBMA Address 
     whose length is the value of the NBMA length field.

     The Next-hop IP Address specifies the IP address of the next hop.
     This will be the address of the destination host if it is directly
     attached to the NBMA subnetwork, or the egress router if it is not
     directly attached.

     The Holding Time is similar in concept the the Holding Time associated
     with the Source NBMA Address but is time specifying the the validity 
     of the destination address specified in the specific Next-hop entry.
     The Holding Time field specifies the number of seconds for which
     the associated Next-hop entry information is considered to be
     valid.  Cached information SHALL be discarded when the holding time
     expires.  (Holding time is to be specified for both positive and
     negative replies).

     The Address Type field specifies the type of NBMA address
     (qualifying the NBMA address).  Possible address types are listed
     in [6].

     The S bit is set if the association between the destination and 
     the next hop information is guaranteed to be stable for the lifetime 
     of the information (the holding time).  This is the case if the Next-hop
     IP address identifies the destination (though it may be different
     in value than the Destination address if the destination system has
     multiple addresses) or if the destination is not connected directly
     to the NBMA subnetwork but the egress router to that destination is
     guaranteed to be stable (such as when the destination is
     immediately adjacent to the egress router through a non-NBMA
     interface).  This information affects caching strategies (see
     section 6.2).

     The Preference field specifies the preference of the Next-hop
     entry, relative to other Next-hop entries in this NHRP Reply
     packet.  Higher values indicate more preferable Next-hop entries.
     Action taken when multiple next-hop entries have the highest
     preference value is a local matter.

     The NBMA length field specifies the length of the NBMA address of
     the destination station in bits.  The NBMA address field itself is
     zero-filled to the nearest 32-bit boundary.  For negative replies,
     the Holding Time field is relevant; however, the preference,
     Address Type, and NBMA length fields MUST be zero, and the NBMA
     Address SHALL NOT be present.

     There may be multiple Next-hop entries returned in the reply
     by including the Additional Next Hop Entries (IP) Extension.
     See Section 5.7.9 for use of these entries.  The most preferable
     Next Hop must be specified in the mandatory part of the reply.

     If extensions were present in the NHRP Request packet, all of these
     extensions MUST be present in the NHRP Reply.  No additional
     extensions may be added to the reply that were not present in the
     request.

   The Request packet may be used to register a station's IP and NBMA addresses
   with its neighboring NHSs. This is done by specifying both the source and 
   destination address to be the client's address.  This registration is
   acknowledged by sending a Reply packet in response to the Request packet.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this is the case, the NHS MUST
   respond with an Error Indication of type Can't Serve This Address not
   simply with a NAK.

   If an NHS cannot serve a station due to a lack of resources, the NHS
   MUST respond with an Error Indication of type Registration Overflow and
   not simply with a NAK.


*********things skipped until extensions section********* 

=============================================================================
5.7.9 Additional Next Hop Entries (IP) Extension

   Discretionary = 1
   Type = 9
   Length = variable

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Next-hop IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Holding Time          |         Address Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|  Preference |  NBMA Length  | NBMA Address (variable length)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               . . . . . . . .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Next-hop IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Holding Time          |         Address Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|  Preference |  NBMA Length  | NBMA Address (variable length)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   There may be multiple Next-hop entries returned in a reply by using
   this extension.  The preference values are used to select the preferred 
   entry.  The same next-hop IP address may be associated with multiple 
   NBMA addresses.  Load-splitting may be performed over the addresses, 
   given equal preference values, and the alternative addresses may be 
   used in case of connectivity failure in the NBMA subnetwork (such 
   as a failed call attempt in connection-oriented NBMA subnetworks).

   Next-hop entry
     The Next-hop IP Address specifies the IP address of the next hop.
     This will be the address of an egress router.

     The Holding Time is similar in concept the the Holding Time associated
     with the Source NBMA Address but is time specifying the the validity 
     of the destination address specified in the specific Next-hop entry.
     The Holding Time field specifies the number of seconds for which
     the associated Next-hop entry information is considered to be
     valid.  Cached information SHALL be discarded when the holding time
     expires.  (Holding time is to be specified for both positive and
     negative replies).

     The Address Type field specifies the type of NBMA address
     (qualifying the NBMA address).  Possible address types are listed
     in [6].

     The S bit is set if the association between the destination and 
     the next hop information is guaranteed to be stable for the lifetime 
     of the information (the holding time).  This is the case if the Next-hop
     IP address identifies the destination (though it may be different
     in value than the Destination address if the destination system has
     multiple addresses) or if the destination is not connected directly
     to the NBMA subnetwork but the egress router to that destination is
     guaranteed to be stable (such as when the destination is
     immediately adjacent to the egress router through a non-NBMA
     interface).  This information affects caching strategies (see
     section 6.2).

     The Preference field specifies the preference of the Next-hop
     entry, relative to other Next-hop entries in this NHRP Reply
     packet.  Higher values indicate more preferable Next-hop entries.
     Action taken when multiple next-hop entries have the highest
     preference value is a local matter.

     The NBMA length field specifies the length of the NBMA address of
     the destination station in bits.  The NBMA address field itself is
     zero-filled to the nearest 32-bit boundary.