tech-invite   World Map     

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

RFC 5971

 
 
 

GIST: General Internet Signalling Transport

Part 3 of 6, p. 45 to 70
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 45 
5.  Message Formats and Transport

5.1.  GIST Messages

   All GIST messages begin with a common header, followed by a sequence
   of type-length-value (TLV) objects.  This subsection describes the
   various GIST messages and their contents at a high level in ABNF
   [11]; a more detailed description of the header and each object is
   given in Section 5.2 and bit formats in Appendix A.  Note that the
   NAT traversal mechanism for GIST involves the insertion of an
   additional NAT-Traversal-Object in Query, Response, and some Data and
   Error messages; the rules for this are given in Section 7.2.

Top      Up      ToC       Page 46 
   GIST-Message: The primary messages are either part of the three-way
   handshake or a simple message carrying NSLP data.  Additional types
   are defined for errors and keeping messaging associations alive.

       GIST-Message = Query / Response / Confirm /
                      Data / Error / MA-Hello

   The common header includes a version number, message type and size,
   and NSLPID.  It also carries a hop count to prevent infinite message
   looping and various control flags, including one (the R-flag) to
   indicate if a reply of some sort is requested.  The objects following
   the common header MUST be carried in a fixed order, depending on
   message type.  Messages with missing, duplicate, or invalid objects
   for the message type MUST be rejected with an "Object Type Error"
   message with the appropriate subcode (Appendix A.4.4.9).  Note that
   unknown objects indicate explicitly how they should be treated and
   are not covered by the above statement.

   Query: A Query MUST be sent in D-mode using the special Q-mode
   encapsulation.  In addition to the common header, it contains certain
   mandatory control objects, and MAY contain a signalling application
   payload.  A stack proposal and configuration data MUST be included if
   the message exchange relates to setup of a messaging association, and
   this is the case even if the Query is intended only for refresh
   (since a routing change might have taken place in the meantime).  The
   R-flag MUST always be set (R=1) in a Query, since this message always
   elicits a Response.

       Query = Common-Header
               [ NAT-Traversal-Object ]
               Message-Routing-Information
               Session-Identifier
               Network-Layer-Information
               Query-Cookie
               [ Stack-Proposal Stack-Configuration-Data ]
               [ NSLP-Data ]

   Response: A Response MUST be sent in D-mode if no existing messaging
   association can be re-used.  If one is being re-used, the Response
   MUST be sent in C-mode.  It MUST echo the MRI, SID, and Query-Cookie
   of the Query, and carries its own Network-Layer-Information.  If the
   message exchange relates to setup of a new messaging association,
   which MUST involve a D-mode Response, a Responder-Cookie MUST be
   included, as well as the Responder's own stack proposal and
   configuration data.  The R-flag MUST be set (R=1) if a Responder-
   Cookie is present but otherwise is optional; if the R-flag is set, a
   Confirm MUST be sent as a reply.  Therefore, in particular, a Confirm
   will always be required if a new MA is being set up.  Note that the

Top      Up      ToC       Page 47 
   direction of this MRI will be inverted compared to that in the Query,
   that is, an upstream MRI becomes downstream and vice versa (see
   Section 3.3).

       Response = Common-Header
                  [ NAT-Traversal-Object ]
                  Message-Routing-Information
                  Session-Identifier
                  Network-Layer-Information
                  Query-Cookie
                  [ Responder-Cookie
                    [ Stack-Proposal Stack-Configuration-Data ] ]
                  [ NSLP-Data ]

   Confirm: A Confirm MUST be sent in C-mode if a messaging association
   is being used for this routing state, and MUST be sent before other
   messages for this routing state if an association is being set up.
   If no messaging association is being used, the Confirm MUST be sent
   in D-mode.  The Confirm MUST include the MRI (with inverted
   direction) and SID, and echo the Responder-Cookie if the Response
   carried one.  In C-mode, the Confirm MUST also echo the Stack-
   Proposal from the Response (if present) so it can be verified that
   this has not been tampered with.  The first Confirm on a new
   association MUST also repeat the Stack-Configuration-Data from the
   original Query in an abbreviated form, just containing the MA-Hold-
   Time.

       Confirm = Common-Header
                 Message-Routing-Information
                 Session-Identifier
                 Network-Layer-Information
                 [ Responder-Cookie
                   [ Stack-Proposal
                     [ Stack-Configuration-Data ] ] ]
                 [ NSLP-Data ]

   Data: The Data message is used to transport NSLP data without
   modifying GIST state.  It contains no control objects, but only the
   MRI and SID associated with the NSLP data being transferred.
   Network-Layer-Information (NLI) MUST be carried in the D-mode case,
   but MUST NOT be included otherwise.

       Data = Common-Header
              [ NAT-Traversal-Object ]
              Message-Routing-Information
              Session-Identifier
              [ Network-Layer-Information ]
              NSLP-Data

Top      Up      ToC       Page 48 
   Error: An Error message reports a problem determined at the GIST
   level.  (Errors generated by signalling applications are reported in
   NSLP-Data payloads and are not treated specially by GIST.)  If the
   message is being sent in D-mode, the originator of the error message
   MUST include its own Network-Layer-Information object.  All other
   information related to the error is carried in a GIST-Error-Data
   object.

       Error = Common-Header
               [ NAT-Traversal-Object ]
               [ Network-Layer-Information ]
               GIST-Error-Data

   MA-Hello: This message MUST be sent only in C-mode.  It contains the
   common header, with a NSLPID of zero, and a message identifier, the
   Hello-ID.  It always indicates that a node wishes to keep a messaging
   association open, and if sent with R=0 and zero Hello-ID this is its
   only function.  A node MAY also invoke a diagnostic request/reply
   exchange by setting R=1 and providing a non-zero Hello-ID; in this
   case, the peer MUST send another MA-Hello back along the messaging
   association echoing the same Hello-ID and with R=0.  Use of this
   diagnostic is entirely at the discretion of the initiating node.

       MA-Hello = Common-Header
                  Hello-ID

5.2.  Information Elements

   This section describes the content of the various objects that can be
   present in each GIST message, both the common header and the
   individual TLVs.  The bit formats are provided in Appendix A.

5.2.1.  The Common Header

   Each message begins with a fixed format common header, which contains
   the following information:

   Version:  The version number of the GIST protocol.  This
      specification defines GIST version 1.

   GIST hop count:  A hop count to prevent a message from looping
      indefinitely.

   Length:  The number of 32-bit words in the message following the
      common header.

   Upper layer identifier (NSLPID):  This gives the specific NSLP for
      which this message is used.

Top      Up      ToC       Page 49 
   Context-free flag:  This flag is set (C=1) if the receiver has to be
      able to process the message without supporting routing state.  The
      C-flag MUST be set for Query messages, and also for Data messages
      sent in Q-mode.  The C-flag is important for NAT traversal
      processing.

   Message type:  The message type (Query, Response, etc.).

   Source addressing mode:  If set (S=1), this indicates that the IP
      source address of the message is the same as the IP address of the
      signalling peer, so replies to this message can be sent safely to
      this address.  S is always set in C-mode.  It is cleared (S=0) if
      the IP source address was derived from the message routing
      information in the payload and this is different from the
      signalling source address.

   Response requested:  A flag that if set (R=1) indicates that a GIST
      message should be sent in reply to this message.  The appropriate
      message type for the reply depends on the type of the initial
      message.

   Explicit routing:  A flag that if set (E=1) indicates that the
      message was explicitly routed (see Section 7.1.5).

   Note that in D-mode, Section 5.3, there is a 32-bit magic number
   before the header.  However, this is regarded as part of the
   encapsulation rather than part of the message itself.

5.2.2.  TLV Objects

   All data following the common header is encoded as a sequence of
   type-length-value objects.  Currently, each object can occur at most
   once; the set of required and permitted objects is determined by the
   message type and encapsulation (D-mode or C-mode).

   Message-Routing-Information (MRI):  Information sufficient to define
      how the signalling message should be routed through the network.

       Message-Routing-Information = message-routing-method
                                     method-specific-information

   The format of the method-specific-information depends on the
   message-routing-method requested by the signalling application.  Note
   that it always includes a flag defining the direction as either
   'upstream' or 'downstream' (see Section 3.3).  It is provided by the
   NSLP in the message sender and used by GIST to select the message
   routing.

Top      Up      ToC       Page 50 
   Session-Identifier (SID):  The GIST session identifier is a 128-bit,
      cryptographically random identifier chosen by the node that
      originates the signalling exchange.  See Section 3.7.

   Network-Layer-Information (NLI):  This object carries information
      about the network layer attributes of the node sending the
      message, including data related to the management of routing
      state.  This includes a peer identity and IP address for the
      sending node.  It also includes IP-TTL information to allow the IP
      hop count between GIST peers to be measured and reported, and a
      validity time (RS-validity-time) for the routing state.

       Network-Layer-Information = peer-identity
                                   interface-address
                                   RS-validity-time
                                   IP-TTL

   The use of the RS-validity-time field is described in Section 4.4.4.
   The peer-identity and interface-address are used for matching
   existing associations, as discussed in Section 4.4.3.

   The interface-address must be routable, i.e., it MUST be usable as a
   destination IP address for packets to be sent back to the node
   generating the signalling message, whether in D-mode or C-mode.  If
   this object is carried in a message with the source addressing mode
   flag S=1, the interface-address MUST match the source address used in
   the IP encapsulation, to assist in legacy NAT detection
   (Section 7.2.1).  If this object is carried in a Query or Confirm,
   the interface-address MUST specifically be set to an address bound to
   an interface associated with the MRI, to allow its use in route
   change handling as discussed in Section 7.1.  A suitable choice is
   the interface that is carrying the outbound flow.  A node may have
   several choices for which of its addresses to use as the
   interface-address.  For example, there may be a choice of IP
   versions, or addresses of limited scope (e.g., link-local), or
   addresses bound to different interfaces in the case of a router or
   multihomed host.  However, some of these interface addresses may not
   be usable by the peer.  A node MUST follow a policy of using a global
   address of the same IP version as in the MRI, unless it can establish
   that an alternative address would also be usable.

   The setting and interpretation of the IP-TTL field depends on the
   message direction (upstream/downstream as determined from the MRI as
   described above) and encapsulation.

      *  If the message is sent downstream, if the TTL that will be set
         in the IP header for the message can be determined, the IP-TTL
         value MUST be set to this value, or else set to 0.

Top      Up      ToC       Page 51 
      *  On receiving a downstream message in D-mode, a non-zero IP-TTL
         is compared to the TTL in the IP header, and the difference is
         stored as the IP-hop-count-to-peer for the upstream peer in the
         routing state table for that flow.  Otherwise, the field is
         ignored.

      *  If the message is sent upstream, the IP-TTL MUST be set to the
         value of the IP-hop-count-to-peer stored in the routing state
         table, or 0 if there is no value yet stored.

      *  On receiving an upstream message, the IP-TTL is stored as the
         IP-hop-count-to-peer for the downstream peer.

      In all cases, the IP-TTL value reported to signalling applications
      is the one stored with the routing state for that flow, after it
      has been updated if necessary from processing the message in
      question.

   Stack-Proposal:  This field contains information about which
      combinations of transport and security protocols are available for
      use in messaging associations, and is also discussed further in
      Section 5.7.

       Stack-Proposal = 1*stack-profile

       stack-profile = protocol-count 1*protocol-layer
                       ;; padded on the right with 0 to 32-bit boundary

       protocol-count = %x01-FF
                       ;; number of the following <protocol-layer>,
                       ;; represented as one byte.  This doesn't include
                       ;; padding.

       protocol-layer = %x01-FF

   Each protocol-layer field identifies a protocol with a unique tag;
   any additional data, such as higher-layer addressing or other options
   data associated with the protocol, will be carried in an
   MA-protocol-options field in the Stack-Configuration-Data TLV (see
   below).

   Stack-Configuration-Data (SCD):  This object carries information
      about the overall configuration of a messaging association.

       Stack-Configuration-Data = MA-Hold-Time
                                  0*MA-protocol-options

Top      Up      ToC       Page 52 
   The MA-Hold-Time field indicates how long a node will hold open an
   inactive association; see Section 4.4.5 for more discussion.  The
   MA-protocol-options fields give the configuration of the protocols
   (e.g., TCP, TLS) to be used for new messaging associations, and they
   are described in more detail in Section 5.7.

   Query-Cookie/Responder-Cookie:  A Query-Cookie is contained in a
      Query and MUST be echoed in a Response; a Responder-Cookie MAY be
      sent in a Response, and if present MUST be echoed in the following
      Confirm.  Cookies are variable-length bit strings, chosen by the
      cookie generator.  See Section 8.5 for further details on
      requirements and mechanisms for cookie generation.

   Hello-ID:  The Hello-ID is a 32-bit quantity that is used to
      correlate messages in an MA-Hello request/reply exchange.  A non-
      zero value MUST be used in a request (messages sent with R=1) and
      the same value must be returned in the reply (which has R=0).  The
      value zero MUST be used for all other messages; if a message is
      received with R=1 and Hello-ID=0, an "Object Value Error" message
      (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be
      returned and the message dropped.  Nodes MAY use any algorithm to
      generate the Hello-ID; a suitable approach is a local sequence
      number with a random starting point.

   NSLP-Data:  The NSLP payload to be delivered to the signalling
      application.  GIST does not interpret the payload content.

   GIST-Error-Data:  This contains the information to report the cause
      and context of an error.

       GIST-Error-Data = error-class error-code error-subcode
                         common-error-header
                         [ Message-Routing-Information-content ]
                         [ Session-Identification-content ]
                         0*additional-information
                         [ comment ]

   The error-class indicates the severity level, and the error-code and
   error-subcode identify the specific error itself.  A full list of
   GIST errors and their severity levels is given in Appendix A.4.  The
   common-error-header carries the Common-Header from the original
   message, and contents of the Message-Routing-Information (MRI) and
   Session-Identifier (SID) objects are also included if they were
   successfully decoded.  For some errors, additional information fields
   can be included, and these fields themselves have a simple TLV
   format.  Finally, an optional free-text comment may be added.

Top      Up      ToC       Page 53 
5.3.  D-mode Transport

   This section describes the various encapsulation options for D-mode
   messages.  Although there are several possibilities, depending on
   message type, MRM, and local policy, the general design principle is
   that the sole purpose of the encapsulation is to ensure that the
   message is delivered to or intercepted at the correct peer.  Beyond
   that, minimal significance is attached to the type of encapsulation
   or the values of addresses or ports used for it.  This allows new
   options to be developed in the future to handle particular deployment
   requirements without modifying the overall protocol specification.

5.3.1.  Normal Encapsulation

   Normal encapsulation MUST be used for all D-mode messages where the
   signalling peer is already known from previous signalling.  This
   includes Response and Confirm messages, and Data messages except if
   these are being sent without using local routing state.  Normal
   encapsulation is simple: the message is carried in a single UDP
   datagram.  UDP checksums MUST be enabled.  The UDP payload MUST
   always begin with a 32-bit magic number with value 0x4e04 bda5 in
   network byte order; this is followed by the GIST common header and
   the complete set of payloads.  If the magic number is not present,
   the message MUST be silently dropped.  The normal encapsulation is
   shown in outline in Figure 6.

         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                          IP Header                          //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                         UDP Header                          //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                GIST Magic Number (0x4e04bda5)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                     GIST Common Header                      //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                        GIST Payloads                        //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6: Normal Encapsulation Packet Format

   The message is IP addressed directly to the adjacent peer as given by
   the routing state table.  Where the message is a direct reply to a
   Query and no routing state exists, the destination address is derived
   from the input message using the same rules as in Section 4.4.1.  The
   UDP port numbering MUST be compatible with that used on Query
   messages (see below), that is, the same for messages in the same

Top      Up      ToC       Page 54 
   direction and with source and destination port numbers swapped for
   messages in the opposite direction.  Messages with the normal
   encapsulation MUST be sent with source addressing mode flag S=1
   unless the message is a reply to a message that is known to have
   passed through a NAT, and the receiver MUST check the IP source
   address with the interface-address given in the NLI as part of legacy
   NAT detection.  Both these aspects of message processing are
   discussed further in Section 7.2.1.

5.3.2.  Q-mode Encapsulation

   Q-mode encapsulation MUST be used for messages where no routing state
   is available or where the routing state is being refreshed, in
   particular, for Query messages.  Q-mode can also be used when
   requested by local policy.  Q-mode encapsulation is similar to normal
   encapsulation, with changes in IP address selection, rules about IP
   options, and a defined method for selecting UDP ports.

   It is an essential property of the Q-mode encapsulation that it is
   possible for a GIST node to intercept these messages efficiently even
   when they are not directly addressed to it and, conversely, that it
   is possible for a non-GIST node to ignore these messages without
   overloading the slow path packet processing.  This document specifies
   that interception is done based on RAOs.

5.3.2.1.  Encapsulation and Interception in IPv4

   In general, the IP addresses are derived from information in the MRI;
   the exact rules depend on the MRM.  For the case of messages with
   source addressing mode flag S=1, the receiver MUST check the IP
   source address against the interface-address given in the NLI as part
   of legacy NAT detection; see Section 7.2.1.

   Current MRMs define the use of a Router Alert Option [13] to assist
   the peer in intercepting the message depending on the NSLPID.  If the
   MRM defines the use of RAO, the sender MUST include it unless it has
   been specifically configured not to (see below).  A node MAY make the
   initial interception decision based purely on IP-Protocol number
   transport header analysis.  Implementations MAY provide an option to
   disable the setting of RAO on Q-mode packets on a per-destination
   prefix basis; however, the option MUST be disabled by default and
   MUST only be enabled when it has been separately verified that the
   next GIST node along the path to the destination is capable of
   intercepting packets without RAO.  The purpose of this option is to
   allow operation across networks that do not properly support RAO;
   further details are discussed in Appendix C.

Top      Up      ToC       Page 55 
   It is likely that fragmented datagrams will not be correctly
   intercepted in the network, since the checks that a datagram is a
   Q-mode packet depend on data beyond the IP header.  Therefore, the
   sender MUST set the Don't Fragment (DF) bit in the IPv4 header.  Note
   that ICMP "packet too large" messages will be sent to the source
   address of the original IP datagram, and since all MRM definitions
   recommend S=1 for at least some retransmissions, ICMP errors related
   to fragmentation will be seen at the Querying node.

   The upper layer protocol, identified by the IP-Protocol field in the
   IP header, MUST be UDP.

5.3.2.2.  Encapsulation and Interception in IPv6

   As for IPv4, the IP addresses are derived from information in the
   MRI; the exact rules depend on the MRM.  For the case of messages
   with source addressing mode flag S=1, the receiver MUST check the IP
   source address with the interface-address given in the NLI as part of
   legacy NAT detection; see Section 7.2.1.

   For all current MRMs, the IP header is given a Router Alert Option
   [8] to assist the peer in intercepting the message depending on the
   NSLPID.  If the MRM defines the use of RAO, the sender MUST include
   it without exception.  It is RECOMMENDED that a node bases its
   initial interception decision purely on the presence of a hop-by-hop
   option header containing the RAO, which will be at the start of the
   header chain.

   The upper layer protocol MUST be UDP without intervening
   encapsulation layers.  Following any hop-by-hop option header, the IP
   header MUST NOT include any extension headers other than routing or
   destination options [5], and for the last extension header MUST have
   a next-header field of UDP.

5.3.2.3.  Upper Layer Encapsulation and Overall Interception
          Requirements

   For both IP versions, the above rules require that the upper layer
   protocol identified by the IP header MUST be UDP.  Other packets MUST
   NOT be identified as GIST Q-mode packets; this includes IP-in-IP
   tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or
   packets that have undergone some additional transport layer
   processing (transport mode AH/ESP).  If IP output processing at the
   originating node or an intermediate router causes such additional
   encapsulations to be added to a GIST Q-mode packet, this packet will
   not be identified as GIST until the encapsulation is terminated.  If
   the node wishes to signal for data over the network region where the

Top      Up      ToC       Page 56 
   encapsulation applies, it MUST generate additional signalling with an
   MRI matching the encapsulated traffic, and the outbound GIST Q-mode
   messages for it MUST bypass the encapsulation processing.

   Therefore, the final stage of the interception process and the final
   part of encapsulation is at the UDP level.  The source UDP port is
   selected by the message sender as the port at which it is prepared to
   receive UDP messages in reply, and the sender MUST use the
   destination UDP port allocated for GIST by IANA (see Section 9).
   Note that for some MRMs, GIST nodes anywhere along the path can
   generate GIST packets with source addresses that spoof the source
   address of the data flow.  Therefore, destinations cannot distinguish
   these packets from genuine end-to-end data purely on address
   analysis.  Instead, it must be possible to distinguish such GIST
   packets by port analysis; furthermore, the mechanism to do so must
   remain valid even if the destination is GIST-unaware.  GIST solves
   this problem by using a fixed destination UDP port from the "well
   known" space for the Q-mode encapsulation.  This port should never be
   allocated on a GIST-unaware host, and therefore Q-mode encapsulated
   messages should always be rejected with an ICMP error.  The usage of
   this destination port by other applications will result in reduced
   performance due to increased delay and packet drop rates due to their
   interception by GIST nodes.

   A GIST node will need to be capable to filter out all IP/UDP packets
   that have a UDP destination port number equal to the one registered
   for GIST Q-mode encapsulation.  These packets SHOULD then be further
   verified to be GIST packets by checking the magic number (see
   Section 5.3.1).  The packets that meet both port and magic number
   requirements are further processed as GIST Q-mode packets.  Any
   filtered packets that fail this GIST magic number check SHOULD be
   forwarded towards the IP packet's destination as a normal IP
   datagram.  To protect against denial-of-service attacks, a GIST node
   SHOULD have a rate limiter preventing more packets (filtered as
   potential Q-mode packets) from being processed than the system can
   safely handle.  Any excess packets SHOULD be discarded.

5.3.2.4.  IP Option Processing

   For both IPv4 and IPv6, for Q-mode packets with IP options allowed by
   the above requirements, IP options processing is intended to be
   carried out independently of GIST processing.  Note that for the
   options allowed by the above rules, the option semantics are
   independent of the payload: UDP payload modifications are not
   prevented by the options and do not affect the option content, and
   conversely the presence of the options does not affect the UDP
   payload.

Top      Up      ToC       Page 57 
   On packets originated by GIST, IP options MAY be added according to
   node-local policies on outgoing IP data.  On packets forwarded by
   GIST without NSLP processing, IP options MUST be processed as for a
   normally forwarded IP packet.  On packets locally delivered to the
   NSLP, the IP options MAY be passed to the NSLP and equivalent options
   used on subsequently generated outgoing Q-mode packets.  In this
   case, routing related options SHOULD be processed identically as they
   would be for a normally forwarded IP packet.

5.3.3.  Retransmission and Rate Control

   D-mode uses UDP, and hence has no automatic reliability or congestion
   control capabilities.  Signalling applications requiring reliability
   should be serviced using C-mode, which should also carry the bulk of
   signalling traffic.  However, some form of messaging reliability is
   required for the GIST control messages themselves, as is rate control
   to handle retransmissions and also bursts of unreliable signalling or
   state setup requests from the signalling applications.

   Query messages that do not receive Responses MAY be retransmitted;
   retransmissions MUST use a binary exponential backoff.  The initial
   timer value is T1, which the backoff process can increase up to a
   maximum value of T2 seconds.  The default value for T1 is 500 ms.  T1
   is an estimate of the round-trip time between the Querying and
   Responding nodes.  Nodes MAY use smaller values of T1 if it is known
   that the Query should be answered within the local network.  T1 MAY
   be chosen larger, and this is RECOMMENDED if it is known in advance
   (such as on high-latency access links) that the round-trip time is
   larger.  The default value of T2 is 64*T1.  Note that Queries may go
   unanswered either because of message loss (in either direction) or
   because there is no reachable GIST peer.  Therefore, implementations
   MAY trade off reliability (large T2) against promptness of error
   feedback to applications (small T2).  If the NSLP has indicated a
   timeout on the validity of this payload (see Appendix B.1), T2 MUST
   be chosen so that the process terminates within this timeout.
   Retransmitted Queries MUST use different Query-Cookie values.  If the
   Query carries NSLP data, it may be delivered multiple times to the
   signalling application.  These rules apply equally to the message
   that first creates routing state, and those that refresh it.  In all
   cases, Responses MUST be sent promptly to avoid spurious
   retransmissions.  Nodes generating any type of retransmission MUST be
   prepared to receive and match a reply to any of them, not just the
   one most recently sent.  Although a node SHOULD terminate its
   retransmission process when any reply is received, it MUST continue
   to process further replies as normal.

Top      Up      ToC       Page 58 
   This algorithm is sufficient to handle lost Queries and Responses.
   The case of a lost Confirm is more subtle.  The Responding node MAY
   run a retransmission timer to resend the Response until a Confirm is
   received; the timer MUST use the same backoff mechanism and
   parameters as for Responses.  The problem of an amplification attack
   stimulated by a malicious Query is handled by requiring the cookie
   mechanism to enable the node receiving the Response to discard it
   efficiently if it does not match a previously sent Query.  This
   approach is only appropriate if the Responding node is prepared to
   store per-flow state after receiving a single (Query) message, which
   includes the case where the node has queued NSLP data.  If the
   Responding node has delayed state installation, the error condition
   will only be detected when a Data message arrives.  This is handled
   as a routing state error (see Section 4.4.6) that causes the Querying
   node to restart the handshake.

   The basic rate-control requirements for D-mode traffic are
   deliberately minimal.  A single rate limiter applies to all traffic,
   for all interfaces and message types.  It applies to retransmissions
   as well as new messages, although an implementation MAY choose to
   prioritise one over the other.  Rate-control applies only to locally
   generated D-mode messages, not to messages that are being forwarded.
   When the rate limiter is in effect, D-mode messages MUST be queued
   until transmission is re-enabled, or they MAY be dropped with an
   error condition indicated back to local signalling applications.  In
   either case, the effect of this will be to reduce the rate at which
   new transactions can be initiated by signalling applications, thereby
   reducing the load on the network.

   The rate-limiting mechanism is implementation-defined, but it is
   RECOMMENDED that a token bucket limiter as described in [33] be used.
   The token bucket MUST be sized to ensure that a node cannot saturate
   the network with D-mode traffic, for example, when re-probing the
   network for multiple flows after a route change.  A suitable approach
   is to restrict the token bucket parameters so that the mean output
   rate is a small fraction of the node's lowest-speed interface.  It is
   RECOMMENDED that this fraction is no more than 5%.  Note that
   according to the rules of Section 4.3.3, in general, D-mode SHOULD
   only be used for Queries and Responses rather than normal signalling
   traffic unless capacity for normal signalling traffic can be
   engineered.

5.4.  C-mode Transport

   It is a requirement of the NTLP defined in [29] that it should be
   able to support bundling of small messages, fragmentation of large
   messages, and message boundary delineation.  TCP provides both
   bundling and fragmentation, but not message boundaries.  However, the

Top      Up      ToC       Page 59 
   length information in the GIST common header allows the message
   boundary to be discovered during parsing.  The bundling together of
   small messages either can be done within the transport protocol or
   can be carried out by GIST during message construction.  Either way,
   two approaches can be distinguished:

   1.  As messages arrive for transmission, they are gathered into a
       bundle until a size limit is reached or a timeout expires (cf.
       the Nagle algorithm of TCP).  This provides maximal efficiency at
       the cost of some latency.

   2.  Messages awaiting transmission are gathered together while the
       node is not allowed to send them, for example, because it is
       congestion controlled.

   The second type of bundling is always appropriate.  For GIST, the
   first type MUST NOT be used for trigger messages (i.e., messages that
   update GIST or signalling application state), but may be appropriate
   for refresh messages (i.e., messages that just extend timers).  These
   distinctions are known only to the signalling applications, but MAY
   be indicated (as an implementation issue) by setting the priority
   transfer attribute (Section 4.1.2).

   It can be seen that all of these transport protocol options can be
   supported by the basic GIST message format already presented.  The
   GIST message, consisting of common header and TLVs, is carried
   directly in the transport protocol, possibly incorporating transport
   layer security protection.  Further messages can be carried in a
   continuous stream.  This specification defines only the use of TCP,
   but other possibilities could be included without additional work on
   message formatting.

5.5.  Message Type/Encapsulation Relationships

   GIST has four primary message types (Query, Response, Confirm, and
   Data) and three possible encapsulation methods (normal D-mode,
   Q-mode, and C-mode).  The combinations of message type and
   encapsulation that are allowed for message transmission are given in
   the table below.  In some cases, there are several possible choices,
   depending on the existence of routing state or messaging
   associations.  The rules governing GIST policy, including whether or
   not to create such state to handle a message, are described
   normatively in the other sections of this specification.  If a
   message that can only be sent in Q-mode or D-mode arrives in C-mode
   or vice versa, this MUST be rejected with an "Incorrect
   Encapsulation" error message (Appendix A.4.4.3).  However, it should
   be noted that the processing of the message at the receiver is not
   otherwise affected by the encapsulation method used, except that the

Top      Up      ToC       Page 60 
   decapsulation process may provide additional information, such as
   translated addresses or IP hop count to be used in the subsequent
   message processing.

   +----------+--------------+---------------------------+-------------+
   |  Message |    Normal    |   Query D-mode (Q-mode)   |    C-mode   |
   |          |    D-mode    |                           |             |
   +----------+--------------+---------------------------+-------------+
   |   Query  |     Never    |   Always, with C-flag=1   |    Never    |
   |          |              |                           |             |
   | Response |   Unless a   |           Never           |     If a    |
   |          |   messaging  |                           |  messaging  |
   |          |  association |                           | association |
   |          |   is being   |                           |   is being  |
   |          |    re-used   |                           |   re-used   |
   |          |              |                           |             |
   |  Confirm |  Only if no  |           Never           |     If a    |
   |          |   messaging  |                           |  messaging  |
   |          |  association |                           | association |
   |          | has been set |                           |   has been  |
   |          |   up or is   |                           |  set up or  |
   |          |     being    |                           |   is being  |
   |          |    re-used   |                           |   re-used   |
   |          |              |                           |             |
   |   Data   |  If routing  | If the MRI can be used to |     If a    |
   |          | state exists |     derive the Q-mode     |  messaging  |
   |          | for the flow | encapsulation, and either | association |
   |          |    but no    |  no routing state exists  |    exists   |
   |          |   messaging  |  or local policy requires |             |
   |          |  association |     Q-mode; MUST have     |             |
   |          |              |          C-flag=1         |             |
   +----------+--------------+---------------------------+-------------+

5.6.  Error Message Processing

   Special rules apply to the encapsulation and transmission of Error
   messages.

   GIST only generates Error messages in reaction to incoming messages.
   Error messages MUST NOT be generated in reaction to incoming Error
   messages.  The routing and encapsulation of the Error message are
   derived from that of the message that caused the error; in
   particular, local routing state is not consulted.  Routing state and
   messaging association state MUST NOT be created to handle the error,
   and Error messages MUST NOT be retransmitted explicitly by GIST,
   although they are subject to the same rate control as other messages.

Top      Up      ToC       Page 61 
   o  If the incoming message was received in D-mode, the error MUST be
      sent in D-mode using the normal encapsulation, using the
      addressing information from the NLI object in the incoming
      message.  If the NLI could not be determined, the error MUST be
      sent to the IP source of the incoming message if the S-flag was
      set in it.  The NLI object in the Error message reports
      information about the originator of the error.

   o  If the incoming message was received over a messaging association,
      the error MUST be sent back over the same messaging association.

   The NSLPID in the common header of the Error message has the value
   zero.  If for any reason the message cannot be sent (for example,
   because it is too large to send in D-mode, or because the MA over
   which the original message arrived has since been closed), an error
   SHOULD be logged locally.  The receiver of the Error message can
   infer the NSLPID for the message that caused the error from the
   Common Header that is embedded in the Error Object.

5.7.  Messaging Association Setup

5.7.1.  Overview

   A key attribute of GIST is that it is flexible in its ability to use
   existing transport and security protocols.  Different transport
   protocols may have performance attributes appropriate to different
   environments; different security protocols may fit appropriately with
   different authentication infrastructures.  Even given an initial
   default mandatory protocol set for GIST, the need to support new
   protocols in the future cannot be ruled out, and secure feature
   negotiation cannot be added to an existing protocol in a backwards-
   compatible way.  Therefore, some sort of capability discovery is
   required.

   Capability discovery is carried out in Query and Response messages,
   using Stack-Proposal and Stack-Configuration-Data (SCD) objects.  If
   a new messaging association is required, it is then set up, followed
   by a Confirm.  Messaging association multiplexing is achieved by
   short-circuiting this exchange by sending the Response or Confirm
   messages on an existing association (Section 4.4.3); whether to do
   this is a matter of local policy.  The end result of this process is
   a messaging association that is a stack of protocols.  If multiple
   associations exist, it is a matter of local policy how to distribute
   messages over them, subject to respecting the transfer attributes
   requested for each message.

Top      Up      ToC       Page 62 
   Every possible protocol for a messaging association has the following
   attributes:

   o  MA-Protocol-ID, a 1-byte IANA-assigned value (see Section 9).

   o  A specification of the (non-negotiable) policies about how the
      protocol should be used, for example, in which direction a
      connection should be opened.

   o  (Depending on the specific protocol:) Formats for an MA-protocol-
      options field to carry the protocol addressing and other
      configuration information in the SCD object.  The format may
      differ depending on whether the field is present in the Query or
      Response.  Some protocols do not require the definition of such
      additional data, in which case no corresponding MA-protocol-
      options field will occur in the SCD object.

   A Stack-Proposal object is simply a list of profiles; each profile is
   a sequence of MA-Protocol-IDs.  A profile lists the protocols in 'top
   to bottom' order (e.g., TLS over TCP).  A Stack-Proposal is generally
   accompanied by an SCD object that carries an MA-protocol-options
   field for any protocol listed in the Stack-Proposal that needs it.
   An MA-protocol-options field may apply globally, to all instances of
   the protocol in the Stack-Proposal, or it can be tagged as applying
   to a specific instance.  The latter approach can for example be used
   to carry different port numbers for TCP depending on whether it is to
   be used with or without TLS.  An message flow that shows several of
   the features of Stack-Proposal and Stack-Configuration-Data formats
   can be found in Appendix D.

   An MA-protocol-options field may also be flagged as not usable; for
   example, a NAT that could not handle SCTP would set this in an MA-
   protocol-options field about SCTP.  A protocol flagged this way MUST
   NOT be used for a messaging association.  If the Stack-Proposal and
   SCD are both present but not consistent, for example, if they refer
   to different protocols, or an MA-protocol-options field refers to a
   non-existent profile, an "Object Value Error" message
   (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack-
   Configuration-Data Mismatch") MUST be returned and the message
   dropped.

   A node generating an SCD object MUST honour the implied protocol
   configurations for the period during which a messaging association
   might be set up; in particular, it MUST be immediately prepared to
   accept incoming datagrams or connections at the protocol/port
   combinations advertised.  This MAY require the creation of listening
   endpoints for the transport and security protocols in question, or a
   node MAY keep a pool of such endpoints open for extended periods.

Top      Up      ToC       Page 63 
   However, the received object contents MUST be retained only for the
   duration of the Query/Response exchange and to allow any necessary
   association setup to complete.  They may become invalid because of
   expired bindings at intermediate NATs, or because the advertising
   node is using agile ports.  Once the setup is complete, or if it is
   not necessary or fails for some reason, the object contents MUST be
   discarded.  A default time of 30 seconds to keep the contents is
   RECOMMENDED.

   A Query requesting messaging association setup always contains a
   Stack-Proposal and SCD object.  The Stack-Proposal MUST only include
   protocol configurations that are suitable for the transfer attributes
   of the messages for which the Querying node wishes to use the
   messaging association.  For example, it should not simply include all
   configurations that the Querying node is capable of supporting.

   The Response always contains a Stack-Proposal and SCD object, unless
   multiplexing (where the Responder decides to use an existing
   association) occurs.  For such a Response, the security protocols
   listed in the Stack-Proposal MUST NOT depend on the Query.  A node
   MAY make different proposals depending on the combination of
   interface and NSLPID.  If multiplexing does occur, which is indicated
   by sending the Response over an existing messaging association, the
   following rules apply:

   o  The re-used messaging association MUST NOT have weaker security
      properties than all of the options that would have been offered in
      the full Response that would have been sent without re-use.

   o  The re-used messaging association MUST have equivalent or better
      transport and security characteristics as at least one of the
      protocol configurations that was offered in the Query.

   Once the messaging association is set up, the Querying node repeats
   the responder's Stack-Proposal over it in the Confirm.  The
   Responding node MUST verify that this has not been changed as part of
   bidding-down attack prevention, as well as verifying the Responder-
   Cookie (Section 8.5).  If either check fails, the Responding node
   MUST NOT create the message routing state (or MUST delete it if it
   already exists) and SHOULD log an error condition locally.  If this
   is the first message on a new MA, the MA MUST be torn down.  See
   Section 8.6 for further discussion.

Top      Up      ToC       Page 64 
5.7.2.  Protocol Definition: Forwards-TCP

   This MA-Protocol-ID denotes a basic use of TCP between peers.
   Support for this protocol is REQUIRED.  If this protocol is offered,
   MA-protocol-options data MUST also be carried in the SCD object.  The
   MA-protocol-options field formats are:

   o  in a Query: no additional options data (the MA-protocol-options
      Length field is zero).

   o  in a Response: 2-byte port number at which the connection will be
      accepted, followed by 2 pad bytes.

   The connection is opened in the forwards direction, from the Querying
   node towards the responder.  The Querying node MAY use any source
   address and source port.  The destination information MUST be derived
   from information in the Response: the address from the interface-
   address from the Network-Layer-Information object and the port from
   the SCD object as described above.

   Associations using Forwards-TCP can carry messages with the transfer
   attribute Reliable=True.  If an error occurs on the TCP connection
   such as a reset, as can be detected for example by a socket exception
   condition, GIST MUST report this to NSLPs as discussed in
   Section 4.1.2.

5.7.3.  Protocol Definition: Transport Layer Security

   This MA-Protocol-ID denotes a basic use of transport layer channel
   security, initially in conjunction with TCP.  Support for this
   protocol in conjunction with TCP is REQUIRED; associations using it
   can carry messages with transfer attributes requesting
   confidentiality or integrity protection.  The specific TLS version
   will be negotiated within the TLS layer itself, but implementations
   MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST
   use the highest protocol version supported by both peers.
   Implementation of TLS1.2 [10] is RECOMMENDED.  GIST nodes supporting
   TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite
   TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS
   ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA.  They MAY negotiate any
   mutually acceptable ciphersuite that provides authentication,
   integrity, and confidentiality.

   The default mode of TLS authentication, which applies in particular
   to the above ciphersuites, uses a client/server X.509 certificate
   exchange.  The Querying node acts as a TLS client, and the Responding
   node acts as a TLS server.  Where one of the above ciphersuites is
   negotiated, the GIST node acting as a server MUST provide a

Top      Up      ToC       Page 65 
   certificate, and MUST request one from the GIST node acting as a TLS
   client.  This allows either server-only or mutual authentication,
   depending on the certificates available to the client and the policy
   applied at the server.

   GIST nodes MAY negotiate other TLS ciphersuites.  In some cases, the
   negotiation of alternative ciphersuites is used to trigger
   alternative authentication procedures, such as the use of pre-shared
   keys [32].  The use of other authentication procedures may require
   additional specification work to define how they can be used as part
   of TLS within the GIST framework, and may or may not require the
   definition of additional MA-Protocol-IDs.

   No MA-protocol-options field is required for this TLS protocol
   definition.  The configuration information for the transport protocol
   over which TLS is running (e.g., TCP port number) is provided by the
   MA-protocol-options for that protocol.

5.7.3.1.  Identity Checking in TLS

   After TLS authentication, a node MUST check the identity presented by
   the peer in order to avoid man-in-the-middle attacks, and verify that
   the peer is authorised to take part in signalling at the GIST layer.
   The authorisation check is carried out by comparing the presented
   identity with each Authorised Peer Database (APD) entry in turn, as
   discussed in Section 4.4.2.  This section defines the identity
   comparison algorithm for a single APD entry.

   For TLS authentication with X.509 certificates, an identity from the
   DNS namespace MUST be checked against each subjectAltName extension
   of type dNSName present in the certificate.  If no such extension is
   present, then the identity MUST be compared to the (most specific)
   Common Name in the Subject field of the certificate.  When matching
   DNS names against dNSName or Common Name fields, matching is case-
   insensitive.  Also, a "*" wildcard character MAY be used as the left-
   most name component in the certificate or identity in the APD.  For
   example, *.example.com in the APD would match certificates for
   a.example.com, foo.example.com, *.example.com, etc., but would not
   match example.com.  Similarly, a certificate for *.example.com would
   be valid for APD identities of a.example.com, foo.example.com,
   *.example.com, etc., but not example.com.

   Additionally, a node MUST verify the binding between the identity of
   the peer to which it connects and the public key presented by that
   peer.  Nodes SHOULD implement the algorithm in Section 6 of [8] for
   general certificate validation, but MAY supplement that algorithm

Top      Up      ToC       Page 66 
   with other validation methods that achieve equivalent levels of
   verification (such as comparing the server certificate against a
   local store of already-verified certificates and identity bindings).

   For TLS authentication with pre-shared keys, the identity in the
   psk_identity_hint (for the server identity, i.e., the Responding
   node) or psk_identity (for the client identity, i.e., the Querying
   node) MUST be compared to the identities in the APD.

5.8.  Specific Message Routing Methods

   Each message routing method (see Section 3.3) requires the definition
   of the format of the message routing information (MRI) and Q-mode
   encapsulation rules.  These are given in the following subsections
   for the MRMs currently defined.  A GIST implementation on a node MUST
   support whatever MRMs are required by the NSLPs on that node; GIST
   implementations SHOULD provide support for both the MRMs defined
   here, in order to minimise deployment barriers for new signalling
   applications that need them.

5.8.1.  The Path-Coupled MRM

5.8.1.1.  Message Routing Information

   For the path-coupled MRM, the message routing information (MRI) is
   conceptually the Flow Identifier as in the NSIS framework [29].
   Minimally, this could just be the flow destination address; however,
   to account for policy-based forwarding and other issues a more
   complete set of header fields SHOULD be specified if possible (see
   Section 4.3.4 and Section 7.2 for further discussion).

       MRI = network-layer-version
             source-address prefix-length
             destination-address prefix-length
             IP-protocol
             diffserv-codepoint
             [ flow-label ]
             [ ipsec-SPI / L4-ports]

   Additional control information defines whether the flow-label, IPsec
   Security Parameters Index (SPI), and port information are present,
   and whether the IP-protocol and diffserv-codepoint fields should be
   interpreted as significant.  The source and destination addresses
   MUST be real node addresses, but prefix lengths other than 32 or 128
   (for IPv4 and IPv6, respectively) MAY be used to implement address
   wildcarding, allowing the MRI to refer to traffic to or from a wider
   address range.  An additional flag defines the message direction
   relative to the MRI (upstream vs. downstream).

Top      Up      ToC       Page 67 
   The MRI format allows a potentially very large number of different
   flag and field combinations.  A GIST implementation that cannot
   interpret the MRI in a message MUST return an "Object Value Error"
   message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported")
   or 2 ("Invalid Flag-Field Combination") and drop the message.

5.8.1.2.  Downstream Q-mode Encapsulation

   Where the signalling message is travelling in the same ('downstream')
   direction as the flow defined by the MRI, the IP addressing for
   Q-mode encapsulated messages is as follows.  Support for this
   encapsulation is REQUIRED.

   o  The destination IP address MUST be the flow destination address as
      given in the MRI of the message payload.

   o  By default, the source address is the flow source address, again
      from the MRI; therefore, the source addressing mode flag in the
      common header S=0.  This provides the best likelihood that the
      message will be correctly routed through any region performing
      per-packet policy-based forwarding or load balancing that takes
      the source address into account.  However, there may be
      circumstances where the use of the signalling source address (S=1)
      is preferable, such as:

      *  In order to receive ICMP error messages about the signalling
         message, such as unreachable port or address.  If these are
         delivered to the flow source rather than the signalling source,
         it will be very difficult for the querying node to detect that
         it is the last GIST node on the path.  Another case is where
         there is an abnormally low MTU along the path, in which case
         the querying node needs to see the ICMP error (recall that
         Q-mode packets are sent with DF set).

      *  In order to receive GIST Error messages where the error message
         sender could not interpret the NLI in the original message.

      *  In order to attempt to run GIST through an unmodified NAT,
         which will only process and translate IP addresses in the IP
         header (see Section 7.2.1).

      Because of these considerations, use of the signalling source
      address is allowed as an option, with use based on local policy.
      A node SHOULD use the flow source address for initial Query
      messages, but SHOULD transition to the signalling source address
      for some retransmissions or as a matter of static configuration,

Top      Up      ToC       Page 68 
      for example, if a NAT is known to be in the path out of a certain
      interface.  The S-flag in the common header tells the message
      receiver which option was used.

   A Router Alert Option is also included in the IP header.  The option
   value depends on the NSLP being signalled for.  In addition, it is
   essential that the Query mimics the actual data flow as closely as
   possible, since this is the basis of how the signalling message is
   attached to the data path.  To this end, GIST SHOULD set the Diffserv
   codepoint and (for IPv6) flow label to match the values in the MRI.

   A GIST implementation SHOULD apply validation checks to the MRI, to
   reject Query messages that are being injected by nodes with no
   legitimate interest in the flow being signalled for.  In general, if
   the GIST node can detect that no flow could arrive over the same
   interface as the Query, it MUST be rejected with an appropriate error
   message.  Such checks apply only to messages with the Q-mode
   encapsulation, since only those messages are required to track the
   flow path.  The main checks are that the IP version used in the
   encapsulation should match that of the MRI and the version(s) used on
   that interface, and that the full range of source addresses (the
   source-address masked with its prefix-length) would pass ingress
   filtering checks.  For these cases, the error message is "MRI
   Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP
   Version Mismatch" or "Ingress Filter Failure"), respectively.

5.8.1.3.  Upstream Q-mode Encapsulation

   In some deployment scenarios, it is desirable to set up routing state
   in the upstream direction (i.e., from flow receiver towards the
   sender).  This could be used to support firewall signalling to
   control traffic from an uncooperative sender, or signalling in
   general where the flow sender was not NSIS-capable.  This capability
   is incorporated into GIST by defining an encapsulation and processing
   rules for sending Query messages upstream.

   In general, it is not possible to determine the hop-by-hop route
   upstream because of asymmetric IP routing.  However, in particular
   cases, the upstream peer can be discovered with a high degree of
   confidence, for example:

   o  The upstream GIST peer is one IP hop away, and can be reached by
      tracing back through the interface on which the flow arrives.

   o  The upstream peer is a border router of a single-homed (stub)
      network.

Top      Up      ToC       Page 69 
   This section defines an upstream Q-mode encapsulation and validation
   checks for when it can be used.  The functionality to generate
   upstream Queries is OPTIONAL, but if received they MUST be processed
   in the normal way with some additional IP TTL checks.  No special
   functionality is needed for this.

   It is possible for routing state at a given node, for a specific MRI
   and NSLPID, to be created by both an upstream Query exchange
   (initiated by the node itself) and a downstream Query exchange (where
   the node is the responder).  If the SIDs are different, these items
   of routing state MUST be considered as independent; if the SIDs
   match, the routing state installed by the downstream exchange MUST
   take precedence, provided that the downstream Query passed ingress
   filtering checks.  The rationale for this is that the downstream
   Query is in general a more reliable way to install state, since it
   directly probes the IP routing infrastructure along the flow path,
   whereas use of the upstream Query depends on the correctness of the
   Querying node's understanding of the topology.

   The details of the encapsulation are as follows:

   o  The destination address SHOULD be the flow source address as given
      in the MRI of the message payload.  An implementation with more
      detailed knowledge of local IP routing MAY use an alternative
      destination address (e.g., the address of its default router).

   o  The source address SHOULD be the signalling node address, so in
      the common header S=1.

   o  A Router Alert Option is included as in the downstream case.

   o  The Diffserv codepoint and (for IPv6) flow label MAY be set to
      match the values from the MRI as in the downstream case, and the
      UDP port selection is also the same.

   o  The IP layer TTL of the message MUST be set to 255.

   The sending GIST implementation SHOULD attempt to send the Query via
   the same interface and to the same link layer neighbour from which
   the data packets of the flow are arriving.

   The receiving GIST node MAY apply validation checks to the message
   and MRI, to reject Query messages that have reached a node at which
   they can no longer be trusted.  In particular, a node SHOULD reject a
   message that has been propagated more than one IP hop, with an
   "Invalid IP layer TTL" error message (Appendix A.4.4.11).  This can
   be determined by examining the received IP layer TTL, similar to the
   generalised IP TTL security mechanism described in [41].

Top      Up      ToC       Page 70 
   Alternatively, receipt of an upstream Query at the flow source MAY be
   used to trigger setup of GIST state in the downstream direction.
   These restrictions may be relaxed in a future version.

5.8.2.  The Loose-End MRM

   The Loose-End MRM is used to discover GIST nodes with particular
   properties in the direction of a given address, for example, to
   discover a NAT along the upstream data path as in [34].

5.8.2.1.  Message Routing Information

   For the loose-end MRM, only a simplified version of the Flow
   Identifier is needed.

       MRI = network-layer-version
             source-address
             destination-address

   The source address is the address of the node initiating the
   discovery process, for example, the node that will be the data
   receiver in the NAT discovery case.  The destination address is the
   address of a node that is expected to be the other side of the node
   to be discovered.  Additional control information defines the
   direction of the message relative to this flow as in the path-coupled
   case.

5.8.2.2.  Downstream Q-mode Encapsulation

   Only one encapsulation is defined for the loose-end MRM; by
   convention, this is referred to as the downstream encapsulation, and
   is defined as follows:

   o  The IP destination address MUST be the destination address as
      given in the MRI of the message payload.

   o  By default, the IP source address is the source address from the
      MRI (S=0).  However, the use of the signalling source address
      (S=1) is allowed as in the case of the path-coupled MRM.

   A Router Alert Option is included in the IP header.  The option value
   depends on the NSLP being signalled for.  There are no special
   requirements on the setting of the Diffserv codepoint, IP layer TTL,
   or (for IPv6) the flow label.  Nor are any special validation checks
   applied.


Next RFC Part