doc: Add RFC documents

1 files changed, 8627 insertions, 0 deletions

diff --git a/doc/rfc/rfc5971.txt b/doc/rfc/rfc5971.txt
new file mode 100644
index 0000000..14aeefb
--- /dev/null
+++ b/doc/rfc/rfc5971.txt
@@ -0,0 +1,8627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    H. Schulzrinne
+Request for Comments: 5971                                   Columbia U.
+Category: Experimental                                        R. Hancock
+ISSN: 2070-1721                                                      RMR
+                                                            October 2010
+
+
+              GIST: General Internet Signalling Transport
+
+Abstract
+
+   This document specifies protocol stacks for the routing and transport
+   of per-flow signalling messages along the path taken by that flow
+   through the network.  The design uses existing transport and security
+   protocols under a common messaging layer, the General Internet
+   Signalling Transport (GIST), which provides a common service for
+   diverse signalling applications.  GIST does not handle signalling
+   application state itself, but manages its own internal state and the
+   configuration of the underlying transport and security protocols to
+   enable the transfer of messages in both directions along the flow
+   path.  The combination of GIST and the lower layer transport and
+   security protocols provides a solution for the base protocol
+   component of the "Next Steps in Signalling" (NSIS) framework.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5971.
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 1]
+
+RFC 5971                          GIST                      October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Requirements Notation and Terminology . . . . . . . . . . . .   5
+   3.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   8
+     3.1.  Overall Design Approach . . . . . . . . . . . . . . . . .   8
+     3.2.  Modes and Messaging Associations  . . . . . . . . . . . .  10
+     3.3.  Message Routing Methods . . . . . . . . . . . . . . . . .  11
+     3.4.  GIST Messages . . . . . . . . . . . . . . . . . . . . . .  13
+     3.5.  GIST Peering Relationships  . . . . . . . . . . . . . . .  14
+     3.6.  Effect on Internet Transparency . . . . . . . . . . . . .  14
+     3.7.  Signalling Sessions . . . . . . . . . . . . . . . . . . .  15
+     3.8.  Signalling Applications and NSLPIDs . . . . . . . . . . .  16
+     3.9.  GIST Security Services  . . . . . . . . . . . . . . . . .  17
+     3.10. Example of Operation  . . . . . . . . . . . . . . . . . .  18
+   4.  GIST Processing Overview  . . . . . . . . . . . . . . . . . .  20
+     4.1.  GIST Service Interface  . . . . . . . . . . . . . . . . .  21
+     4.2.  GIST State  . . . . . . . . . . . . . . . . . . . . . . .  23
+     4.3.  Basic GIST Message Processing . . . . . . . . . . . . . .  25
+     4.4.  Routing State and Messaging Association Maintenance . . .  33
+   5.  Message Formats and Transport . . . . . . . . . . . . . . . .  45
+     5.1.  GIST Messages . . . . . . . . . . . . . . . . . . . . . .  45
+     5.2.  Information Elements  . . . . . . . . . . . . . . . . . .  48
+     5.3.  D-mode Transport  . . . . . . . . . . . . . . . . . . . .  53
+     5.4.  C-mode Transport  . . . . . . . . . . . . . . . . . . . .  58
+     5.5.  Message Type/Encapsulation Relationships  . . . . . . . .  59
+     5.6.  Error Message Processing  . . . . . . . . . . . . . . . .  60
+     5.7.  Messaging Association Setup . . . . . . . . . . . . . . .  61
+     5.8.  Specific Message Routing Methods  . . . . . . . . . . . .  66
+   6.  Formal Protocol Specification . . . . . . . . . . . . . . . .  71
+     6.1.  Node Processing . . . . . . . . . . . . . . . . . . . . .  73
+     6.2.  Query Node Processing . . . . . . . . . . . . . . . . . .  75
+     6.3.  Responder Node Processing . . . . . . . . . . . . . . . .  79
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 2]
+
+RFC 5971                          GIST                      October 2010
+
+
+     6.4.  Messaging Association Processing  . . . . . . . . . . . .  83
+   7.  Additional Protocol Features  . . . . . . . . . . . . . . . .  86
+     7.1.  Route Changes and Local Repair  . . . . . . . . . . . . .  86
+     7.2.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . .  93
+     7.3.  Interaction with IP Tunnelling  . . . . . . . . . . . . .  99
+     7.4.  IPv4-IPv6 Transition and Interworking . . . . . . . . . . 100
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 101
+     8.1.  Message Confidentiality and Integrity . . . . . . . . . . 102
+     8.2.  Peer Node Authentication  . . . . . . . . . . . . . . . . 102
+     8.3.  Routing State Integrity . . . . . . . . . . . . . . . . . 103
+     8.4.  Denial-of-Service Prevention and Overload Protection  . . 104
+     8.5.  Requirements on Cookie Mechanisms . . . . . . . . . . . . 106
+     8.6.  Security Protocol Selection Policy  . . . . . . . . . . . 108
+     8.7.  Residual Threats  . . . . . . . . . . . . . . . . . . . . 109
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
+   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 117
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 118
+     11.1. Normative References  . . . . . . . . . . . . . . . . . . 118
+     11.2. Informative References  . . . . . . . . . . . . . . . . . 119
+   Appendix A.  Bit-Level Formats and Error Messages . . . . . . . . 122
+     A.1.  The GIST Common Header  . . . . . . . . . . . . . . . . . 122
+     A.2.  General Object Format . . . . . . . . . . . . . . . . . . 123
+     A.3.  GIST TLV Objects  . . . . . . . . . . . . . . . . . . . . 125
+     A.4.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . . 134
+   Appendix B.  API between GIST and Signalling Applications . . . . 143
+     B.1.  SendMessage . . . . . . . . . . . . . . . . . . . . . . . 143
+     B.2.  RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 145
+     B.3.  MessageStatus . . . . . . . . . . . . . . . . . . . . . . 146
+     B.4.  NetworkNotification . . . . . . . . . . . . . . . . . . . 147
+     B.5.  SetStateLifetime  . . . . . . . . . . . . . . . . . . . . 148
+     B.6.  InvalidateRoutingState  . . . . . . . . . . . . . . . . . 148
+   Appendix C.  Deployment Issues with Router Alert Options  . . . . 149
+   Appendix D.  Example Routing State Table and Handshake  . . . . . 151
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 3]
+
+RFC 5971                          GIST                      October 2010
+
+
+1.  Introduction
+
+   Signalling involves the manipulation of state held in network
+   elements.  'Manipulation' could mean setting up, modifying, and
+   tearing down state; or it could simply mean the monitoring of state
+   that is managed by other mechanisms.  This specification concentrates
+   mainly on path-coupled signalling, controlling resources on network
+   elements that are located on the path taken by a particular data
+   flow, possibly including but not limited to the flow endpoints.
+   Examples of state management include network resource reservation,
+   firewall configuration, and state used in active networking; examples
+   of state monitoring are the discovery of instantaneous path
+   properties, such as available bandwidth or cumulative queuing delay.
+   Each of these different uses of signalling is referred to as a
+   signalling application.
+
+   GIST assumes other mechanisms are responsible for controlling routing
+   within the network, and GIST is not designed to set up or modify
+   paths itself; therefore, it is complementary to protocols like
+   Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [22] or
+   LDP [23] rather than an alternative.  There are almost always more
+   than two participants in a path-coupled signalling session, although
+   there is no need for every node on the path to participate; indeed,
+   support for GIST and any signalling applications imposes a
+   performance cost, and deployment for flow-level signalling is much
+   more likely on edge devices than core routers.  GIST path-coupled
+   signalling does not directly support multicast flows, but the current
+   GIST design could be extended to do so, especially in environments
+   where the multicast replication points can be made GIST-capable.
+   GIST can also be extended to cover other types of signalling pattern,
+   not related to any end-to-end flow in the network, in which case the
+   distinction between GIST and end-to-end higher-layer signalling will
+   be drawn differently or not at all.
+
+   Every signalling application requires a set of state management
+   rules, as well as protocol support to exchange messages along the
+   data path.  Several aspects of this protocol support are common to
+   all or a large number of signalling applications, and hence can be
+   developed as a common protocol.  The NSIS framework given in [29]
+   provides a rationale for a function split between the common and
+   application-specific protocols, and gives outline requirements for
+   the former, the NSIS Transport Layer Protocol (NTLP).  Several
+   concepts in the framework are derived from RSVP [14], as are several
+   aspects of the GIST protocol design.  The application-specific
+   protocols are referred to as NSIS Signalling Layer Protocols (NSLPs),
+   and are defined in separate documents.  The NSIS framework [29] and
+   the accompanying threats document [30] provide important background
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 4]
+
+RFC 5971                          GIST                      October 2010
+
+
+   information to this specification, including information on how GIST
+   is expected to be used in various network types and what role it is
+   expected to perform.
+
+   This specification provides a concrete solution for the NTLP.  It is
+   based on the use of existing transport and security protocols under a
+   common messaging layer, the General Internet Signalling Transport
+   (GIST).  GIST does not handle signalling application state itself; in
+   that crucial respect, it differs from higher layer signalling
+   protocols such as SIP, the Real-time Streaming Protocol (RTSP), and
+   the control component of FTP.  Instead, GIST manages its own internal
+   state and the configuration of the underlying transport and security
+   protocols to ensure the transfer of signalling messages on behalf of
+   signalling applications in both directions along the flow path.  The
+   purpose of GIST is thus to provide the common functionality of node
+   discovery, message routing, and message transport in a way that is
+   simple for multiple signalling applications to re-use.
+
+   The structure of this specification is as follows.  Section 2 defines
+   terminology, and Section 3 gives an informal overview of the protocol
+   design principles and operation.  The normative specification is
+   contained mainly in Section 4 to Section 8.  Section 4 describes the
+   message sequences and Section 5 their format and contents.  Note that
+   the detailed bit formats are given in Appendix A.  The protocol
+   operation is captured in the form of state machines in Section 6.
+   Section 7 describes some more advanced protocol features, and
+   security considerations are contained in Section 8.  In addition,
+   Appendix B describes an abstract API for the service that GIST
+   provides to signalling applications, and Appendix D provides an
+   example message flow.  Parts of the GIST design use packets with IP
+   options to probe the network, that leads to some migration issues in
+   the case of IPv4, and these are discussed in Appendix C.
+
+   Because of the layered structure of the NSIS protocol suite, protocol
+   extensions to cover a new signalling requirement could be carried out
+   either within GIST, or within the signalling application layer, or
+   both.  General guidelines on how to extend different layers of the
+   protocol suite, and in particular when and how it is appropriate to
+   extend GIST, are contained in a separate document [12].  In this
+   document, Section 9 gives the formal IANA considerations for the
+   registries defined by the GIST specification.
+
+2.  Requirements Notation and Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 5]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The terminology used in this specification is defined in this
+   section.  The basic entities relevant at the GIST level are shown in
+   Figure 1.  In particular, this diagram distinguishes the different
+   address types as being associated with a flow (end-to-end addresses)
+   or signalling (addresses of adjacent signalling peers).
+
+   Source                 GIST (adjacent) peer nodes         Destination
+
+   IP address              IP addresses = Signalling         IP address
+   = Flow                Source/Destination Addresses        = Flow
+   Source             (depending on signalling direction)    Destination
+   Address                  |                   |            Address
+                            V                   V
+   +--------+           +------+  Data Flow  +------+         +--------+
+   |  Flow  |-----------|------|-------------|------|-------->|  Flow  |
+   | Sender |           |      |             |      |         |Receiver|
+   +--------+           | GIST |============>| GIST |         +--------+
+                        | Node |<============| Node |
+                        +------+  Signalling  +------+
+                          GN1       Flow       GN2
+
+                  >>>>>>>>>>>>>>>>>  =  Downstream direction
+                  <<<<<<<<<<<<<<<<<  =  Upstream direction
+
+                        Figure 1: Basic Terminology
+
+   [Data] Flow:  A set of packets identified by some fixed combination
+      of header fields.  Flows are unidirectional; a bidirectional
+      communication is considered a pair of unidirectional flows.
+
+   Session:  A single application layer exchange of information for
+      which some state information is to be manipulated or monitored.
+      See Section 3.7 for further detailed discussion.
+
+   Session Identifier (SID):  An identifier for a session; the syntax is
+      a 128-bit value that is opaque to GIST.
+
+   [Flow] Sender:  The node in the network that is the source of the
+      packets in a flow.  A sender could be a host, or a router if, for
+      example, the flow is actually an aggregate.
+
+   [Flow] Receiver:  The node in the network that is the sink for the
+      packets in a flow.
+
+   Downstream:  In the same direction as the data flow.
+
+   Upstream:  In the opposite direction to the data flow.
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 6]
+
+RFC 5971                          GIST                      October 2010
+
+
+   GIST Node:  Any node supporting the GIST protocol, regardless of what
+      signalling applications it supports.
+
+   [Adjacent] Peer:  The next node along the signalling path, in the
+      upstream or downstream direction, with which a GIST node
+      explicitly interacts.
+
+   Querying Node:  The GIST node that initiates the handshake process to
+      discover the adjacent peer.
+
+   Responding Node:  The GIST node that responds to the handshake,
+      becoming the adjacent peer to the Querying node.
+
+   Datagram Mode (D-mode):  A mode of sending GIST messages between
+      nodes without using any transport layer state or security
+      protection.  Datagram mode uses UDP encapsulation, with source and
+      destination IP addresses derived either from the flow definition
+      or previously discovered adjacency information.
+
+   Connection Mode (C-mode):  A mode of sending GIST messages directly
+      between nodes using point-to-point messaging associations (see
+      below).  Connection mode allows the re-use of existing transport
+      and security protocols where such functionality is required.
+
+   Messaging Association (MA):  A single connection between two
+      explicitly identified GIST adjacent peers, i.e., between a given
+      signalling source and destination address.  A messaging
+      association may use a transport protocol; if security protection
+      is required, it may use a network layer security association, or
+      use a transport layer security association internally.  A
+      messaging association is bidirectional: signalling messages can be
+      sent over it in either direction, referring to flows of either
+      direction.
+
+   [Message] Routing:  Message routing describes the process of
+      determining which is the next GIST peer along the signalling path.
+      For signalling along a flow path, the message routing carried out
+      by GIST is built on top of normal IP routing, that is, forwarding
+      packets within the network layer based on their destination IP
+      address.  In this document, the term 'routing' generally refers to
+      GIST message routing unless particularly specified.
+
+   Message Routing Method (MRM):  There can be different algorithms for
+      discovering the route that signalling messages should take.  These
+      are referred to as message routing methods, and GIST supports
+      alternatives within a common protocol framework.  See Section 3.3.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 7]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Message Routing Information (MRI):  The set of data item values that
+      is used to route a signalling message according to a particular
+      MRM; for example, for routing along a flow path, the MRI includes
+      flow source and destination addresses, and protocol and port
+      numbers.  See Section 3.3.
+
+   Router Alert Option (RAO):  An option that can be included in IPv4
+      and v6 headers to assist in the packet interception process; see
+      [13] and [17].
+
+   Transfer Attributes:  A description of the requirements that a
+      signalling application has for the delivery of a particular
+      message; for example, whether the message should be delivered
+      reliably.  See Section 4.1.2.
+
+3.  Design Overview
+
+3.1.  Overall Design Approach
+
+   The generic requirements identified in the NSIS framework [29] for
+   transport of signalling messages are essentially two-fold:
+
+   Routing:  Determine how to reach the adjacent signalling node along
+      each direction of the data path (the GIST peer), and if necessary
+      explicitly establish addressing and identity information about
+      that peer;
+
+   Transport:  Deliver the signalling information to that peer.
+
+   To meet the routing requirement, one possibility is for the node to
+   use local routing state information to determine the identity of the
+   GIST peer explicitly.  GIST defines a three-way handshake that probes
+   the network to set up the necessary routing state between adjacent
+   peers, during which signalling applications can also exchange data.
+   Once the routing decision has been made, the node has to select a
+   mechanism for transport of the message to the peer.  GIST divides the
+   transport functionality into two parts, a minimal capability provided
+   by GIST itself, with the use of well-understood transport protocols
+   for the harder cases.  Here, with details discussed later, the
+   minimal capability is restricted to messages that are sized well
+   below the lowest maximum transmission unit (MTU) along a path, are
+   infrequent enough not to cause concerns about congestion and flow
+   control, and do not need security protection or guaranteed delivery.
+
+   In [29], all of these routing and transport requirements are assigned
+   to a single notional protocol, the NSIS Transport Layer Protocol
+   (NTLP).  The strategy of splitting the transport problem leads to a
+   layered structure for the NTLP, with a specialised GIST messaging
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 8]
+
+RFC 5971                          GIST                      October 2010
+
+
+   layer running over standard transport and security protocols.  The
+   basic concept is shown in Figure 2.  Note that not every combination
+   of transport and security protocols implied by the figure is actually
+   possible for use in GIST; the actual combinations allowed by this
+   specification are defined in Section 5.7.  The figure also shows GIST
+   offering its services to upper layers at an abstract interface, the
+   GIST API, further discussed in Section 4.1.
+
+          ^^                      +-------------+
+          ||                      |  Signalling |
+         NSIS        +------------|Application 2|
+       Signalling    | Signalling +-------------+
+      Application    |Application 1|         |
+         Level       +-------------+         |
+          ||             |                   |
+          VV             |                   |
+                 ========|===================|=====  <-- GIST API
+                         |                   |
+          ^^       +------------------------------------------------+
+          ||       |+-----------------------+      +--------------+ |
+          ||       ||         GIST          |      | GIST State   | |
+          ||       ||     Encapsulation     |<<<>>>| Maintenance  | |
+          ||       |+-----------------------+      +--------------+ |
+          ||       | GIST: Messaging Layer                          |
+          ||       +------------------------------------------------+
+         NSIS                 |       |       |       |
+       Transport      ..........................................
+         Level        . Transport Layer Security (TLS or DTLS) .
+        (NTLP)        ..........................................
+          ||                  |       |       |       |
+          ||                +----+  +----+  +----+  +----+
+          ||                |UDP |  |TCP |  |SCTP|  |DCCP| ... other
+          ||                +----+  +----+  +----+  +----+     protocols
+          ||                  |       |       |       |
+          ||                .............................
+          ||                .     IP Layer Security     .
+          ||                .............................
+          VV                  |       |       |       |
+   ===========================|=======|=======|=======|============
+                              |       |       |       |
+                   +----------------------------------------------+
+                   |                      IP                      |
+                   +----------------------------------------------+
+
+      Figure 2: Protocol Stack Architecture for Signalling Transport
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                      [Page 9]
+
+RFC 5971                          GIST                      October 2010
+
+
+3.2.  Modes and Messaging Associations
+
+   Internally, GIST has two modes of operation:
+
+   Datagram mode (D-mode):  used for small, infrequent messages with
+      modest delay constraints and no security requirements.  A special
+      case of D-mode called Query-mode (Q-mode) is used when no routing
+      state exists.
+
+   Connection mode (C-mode):  used for all other signalling traffic.  In
+      particular, it can support large messages and channel security and
+      provides congestion control for signalling traffic.
+
+   C-mode can in principle use any stream or message-oriented transport
+   protocol; this specification defines TCP as the initial choice.  It
+   can in principle employ specific network layer security associations,
+   or an internal transport layer security association; this
+   specification defines TLS as the initial choice.  When GIST messages
+   are carried in C-mode, they are treated just like any other traffic
+   by intermediate routers between the GIST peers.  Indeed, it would be
+   impossible for intermediate routers to carry out any processing on
+   the messages without terminating the transport and security protocols
+   used.
+
+   D-mode uses UDP, as a suitable NAT-friendly encapsulation that does
+   not require per-message shared state to be maintained between the
+   peers.  Long-term evolution of GIST is assumed to preserve the
+   simplicity of the current D-mode design.  Any extension to the
+   security or transport capabilities of D-mode can be viewed as the
+   selection of a different protocol stack under the GIST messaging
+   layer; this is then equivalent to defining another option within the
+   overall C-mode framework.  This includes both the case of using
+   existing protocols and the specific development of a message exchange
+   and payload encapsulation to support GIST requirements.
+   Alternatively, if any necessary parameters (e.g., a shared secret for
+   use in integrity or confidentiality protection) can be negotiated
+   out-of-band, then the additional functions can be added directly to
+   D-mode by adding an optional object to the message (see
+   Appendix A.2.1).  Note that in such an approach, downgrade attacks as
+   discussed in Section 8.6 would need to be prevented by policy at the
+   destination node.
+
+   It is possible to mix these two modes along a path.  This allows, for
+   example, the use of D-mode at the edges of the network and C-mode
+   towards the core.  Such combinations may make operation more
+   efficient for mobile endpoints, while allowing shared security
+   associations and transport connections to be used for messages for
+   multiple flows and signalling applications.  The setup for these
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 10]
+
+RFC 5971                          GIST                      October 2010
+
+
+   protocols imposes an initialisation cost for the use of C-mode, but
+   in the long term this cost can be shared over all signalling sessions
+   between peers; once the transport layer state exists, retransmission
+   algorithms can operate much more aggressively than would be possible
+   in a pure D-mode design.
+
+   It must be understood that the routing and transport functions within
+   GIST are not independent.  If the message transfer has requirements
+   that require C-mode, for example, if the message is so large that
+   fragmentation is required, this can only be used between explicitly
+   identified nodes.  In such cases, GIST carries out the three-way
+   handshake initially in D-mode to identify the peer and then sets up
+   the necessary connections if they do not already exist.  It must also
+   be understood that the signalling application does not make the
+   D-mode/C-mode selection directly; rather, this decision is made by
+   GIST on the basis of the message characteristics and the transfer
+   attributes stated by the application.  The distinction is not visible
+   at the GIST service interface.
+
+   In general, the state associated with C-mode messaging to a
+   particular peer (signalling destination address, protocol and port
+   numbers, internal protocol configuration, and state information) is
+   referred to as a messaging association (MA).  MAs are totally
+   internal to GIST (they are not visible to signalling applications).
+   Although GIST may be using an MA to deliver messages about a
+   particular flow, there is no direct correspondence between them: the
+   GIST message routing algorithms consider each message in turn and
+   select an appropriate MA to transport it.  There may be any number of
+   MAs between two GIST peers although the usual case is zero or one,
+   and they are set up and torn down by management actions within GIST
+   itself.
+
+3.3.  Message Routing Methods
+
+   The baseline message routing functionality in GIST is that signalling
+   messages follow a route defined by an existing flow in the network,
+   visiting a subset of the nodes through which it passes.  This is the
+   appropriate behaviour for application scenarios where the purpose of
+   the signalling is to manipulate resources for that flow.  However,
+   there are scenarios for which other behaviours are applicable.  Two
+   examples are:
+
+   Predictive Routing:  Here, the intent is to signal along a path that
+      the data flow may follow in the future.  Possible cases are pre-
+      installation of state on the backup path that would be used in the
+      event of a link failure, and predictive installation of state on
+      the path that will be used after a mobile node handover.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 11]
+
+RFC 5971                          GIST                      October 2010
+
+
+   NAT Address Reservations:  This applies to the case where a node
+      behind a NAT wishes to reserve an address at which it can be
+      reached by a sender on the other side.  This requires a message to
+      be sent outbound from what will be the flow receiver although no
+      reverse routing state for the flow yet exists.
+
+   Most of the details of GIST operation are independent of the routing
+   behaviour being used.  Therefore, the GIST design encapsulates the
+   routing-dependent details as a message routing method (MRM), and
+   allows multiple MRMs to be defined.  This specification defines the
+   path-coupled MRM, corresponding to the baseline functionality
+   described above, and a second ("Loose-End") MRM for the NAT Address
+   Reservation case.  The detailed specifications are given in
+   Section 5.8.
+
+   The content of an MRM definition is as follows, using the path-
+   coupled MRM as an example:
+
+   o  The format of the information that describes the path that the
+      signalling should take, the Message Routing Information (MRI).
+      For the path-coupled MRM, this is just the flow identifier (see
+      Section 5.8.1.1) and some additional control information.
+      Specifically, the MRI always includes a flag to distinguish
+      between the two directions that signalling messages can take,
+      denoted 'upstream' and 'downstream'.
+
+   o  A specification of the IP-level encapsulation of the messages
+      which probe the network to discover the adjacent peers.  A
+      downstream encapsulation must be defined; an upstream
+      encapsulation is optional.  For the path-coupled MRM, this
+      information is given in Section 5.8.1.2 and Section 5.8.1.3.
+      Current MRMs rely on the interception of probe messages in the
+      data plane, but other mechanisms are also possible within the
+      overall GIST design and would be appropriate for other types of
+      signalling pattern.
+
+   o  A specification of what validation checks GIST should apply to the
+      probe messages, for example, to protect against IP address
+      spoofing attacks.  The checks may be dependent on the direction
+      (upstream or downstream) of the message.  For the path-coupled
+      MRM, the downstream validity check is basically a form of ingress
+      filtering, also discussed in Section 5.8.1.2.
+
+   o  The mechanism(s) available for route change detection, i.e., any
+      change in the neighbour relationships that the MRM discovers.  The
+      default case for any MRM is soft-state refresh, but additional
+      supporting techniques may be possible; see Section 7.1.2.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 12]
+
+RFC 5971                          GIST                      October 2010
+
+
+   In addition, it should be noted that NAT traversal may require
+   translation of fields in the MRI object carried in GIST messages (see
+   Section 7.2.2).  The generic MRI format includes a flag that must be
+   given as part of the MRM definition, to indicate if some kind of
+   translation is necessary.  Development of a new MRM therefore
+   includes updates to the GIST specification, and may include updates
+   to specifications of NAT behaviour.  These updates may be done in
+   separate documents as is the case for NAT traversal for the MRMs of
+   the base GIST specification, as described in Section 7.2.3 and [44].
+
+   The MRI is passed explicitly between signalling applications and
+   GIST; therefore, signalling application specifications must define
+   which MRMs they require.  Signalling applications may use fields in
+   the MRI in their packet classifiers; if they use additional
+   information for packet classification, this would be carried at the
+   NSLP level and so would be invisible to GIST.  Any node hosting a
+   particular signalling application needs to use a GIST implementation
+   that supports the corresponding MRMs.  The GIST processing rules
+   allow nodes not hosting the signalling application to ignore messages
+   for it at the GIST level, so it does not matter if these nodes
+   support the MRM or not.
+
+3.4.  GIST Messages
+
+   GIST has six message types: Query, Response, Confirm, Data, Error,
+   and MA-Hello.  Apart from the invocation of the messaging association
+   protocols used by C-mode, all GIST communication consists of these
+   messages.  In addition, all signalling application data is carried as
+   additional payloads in these messages, alongside the GIST
+   information.
+
+   The Query, Response, and Confirm messages implement the handshake
+   that GIST uses to set up routing state and messaging associations.
+   The handshake is initiated from the Querying node towards the
+   Responding node.  The first message is the Query, which is
+   encapsulated in a specific way depending on the message routing
+   method, in order to probe the network infrastructure so that the
+   correct peer will intercept it and become the Responding node.  A
+   Query always triggers a Response in the reverse direction as the
+   second message of the handshake.  The content of the Response
+   controls whether a Confirm message is sent: as part of the defence
+   against denial-of-service attacks, the Responding node can delay
+   state installation until a return routability check has been
+   performed, and require the Querying node to complete the handshake
+   with the Confirm message.  In addition, if the handshake is being
+   used to set up a new MA, the Response is required to request a
+   Confirm.  All of these three messages can optionally carry signalling
+   application data.  The handshake is fully described in Section 4.4.1.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 13]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The Data message is used purely to encapsulate and deliver signalling
+   application data.  Usually, it is sent using pre-established routing
+   state.  However, if there are no security or transport requirements
+   and no need for persistent reverse routing state, it can also be sent
+   in the same way as the Query.  Finally, Error messages are used to
+   indicate error conditions at the GIST level, and the MA-Hello message
+   can be used as a diagnostic and keepalive for the messaging
+   association protocols.
+
+3.5.  GIST Peering Relationships
+
+   Peering is the process whereby two GIST nodes create message routing
+   states that point to each other.
+
+   A peering relationship can only be created by a GIST handshake.
+   Nodes become peers when one issues a Query and gets a Response from
+   another.  Issuing the initial Query is a result of an NSLP request on
+   that node, and the Query itself is formatted according to the rules
+   of the message routing method.  For current MRMs, the identity of the
+   Responding node is not known explicitly at the time the Query is
+   sent; instead, the message is examined by nodes along the path until
+   one decides to send a Response, thereby becoming the peer.  If the
+   node hosts the NSLP, local GIST and signalling application policy
+   determine whether to peer; the details are given in Section 4.3.2.
+   Nodes not hosting the NSLP forward the Query transparently
+   (Section 4.3.4).  Note that the design of the Query message (see
+   Section 5.3.2) is such that nodes have to opt-in specifically to
+   carry out the message interception -- GIST-unaware nodes see the
+   Query as a normal data packet and so forward it transparently.
+
+   An existing peering relationship can only be changed by a new GIST
+   handshake; in other words, it can only change when routing state is
+   refreshed.  On a refresh, if any of the factors in the original
+   peering process have changed, the peering relationship can also
+   change.  As well as network-level rerouting, changes could include
+   modifications to NSIS signalling functions deployed at a node, or
+   alterations to signalling application policy.  A change could cause
+   an existing node to drop out of the signalling path, or a new node to
+   become part of it.  All these possibilities are handled as rerouting
+   events by GIST; further details of the process are described in
+   Section 7.1.
+
+3.6.  Effect on Internet Transparency
+
+   GIST relies on routers inside the network to intercept and process
+   packets that would normally be transmitted end-to-end.  This
+   processing may be non-transparent: messages may be forwarded with
+   modifications, or not forwarded at all.  This interception applies
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 14]
+
+RFC 5971                          GIST                      October 2010
+
+
+   only to the encapsulation used for the Query messages that probe the
+   network, for example, along a flow path; all other GIST messages are
+   handled only by the nodes to which they are directly addressed, i.e.,
+   as normal Internet traffic.
+
+   Because this interception potentially breaks Internet transparency
+   for packets that have nothing to do with GIST, the encapsulation used
+   by GIST in this case (called Query-mode or Q-mode) has several
+   features to avoid accidental collisions with other traffic:
+
+   o  Q-mode messages are always sent as UDP traffic, and to a specific
+      well-known port (270) allocated by IANA.
+
+   o  All GIST messages sent as UDP have a magic number as the first 32-
+      bit word of the datagram payload.
+
+   Even if a node intercepts a packet as potentially a GIST message,
+   unless it passes both these checks it will be ignored at the GIST
+   level and forwarded transparently.  Further discussion of the
+   reception process is in Section 4.3.1 and the encapsulation in
+   Section 5.3.
+
+3.7.  Signalling Sessions
+
+   GIST requires signalling applications to associate each of their
+   messages with a signalling session.  Informally, given an application
+   layer exchange of information for which some network control state
+   information is to be manipulated or monitored, the corresponding
+   signalling messages should be associated with the same session.
+   Signalling applications provide the session identifier (SID) whenever
+   they wish to send a message, and GIST reports the SID when a message
+   is received; on messages forwarded at the GIST level, the SID is
+   preserved unchanged.  Usually, NSLPs will preserve the SID value
+   along the entire signalling path, but this is not enforced by or even
+   visible to GIST, which only sees the scope of the SID as the single
+   hop between adjacent NSLP peers.
+
+   Most GIST processing and state information is related to the flow
+   (defined by the MRI; see above) and signalling application (given by
+   the NSLP identifier, see below).  There are several possible
+   relationships between flows and sessions, for example:
+
+   o  The simplest case is that all signalling messages for the same
+      flow have the same SID.
+
+   o  Messages for more than one flow may use the same SID, for example,
+      because one flow is replacing another in a mobility or multihoming
+      scenario.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 15]
+
+RFC 5971                          GIST                      October 2010
+
+
+   o  A single flow may have messages for different SIDs, for example,
+      from independently operating signalling applications.
+
+   Because of this range of options, GIST does not perform any
+   validation on how signalling applications map between flows and
+   sessions, nor does it perform any direct validation on the properties
+   of the SID itself, such as any enforcement of uniqueness.  GIST only
+   defines the syntax of the SID as an opaque 128-bit identifier.
+
+   The SID assignment has the following impact on GIST processing:
+
+   o  Messages with the same SID that are to be delivered reliably
+      between the same GIST peers are delivered in order.
+
+   o  All other messages are handled independently.
+
+   o  GIST identifies routing state (upstream and downstream peer) by
+      the MRI/SID/NSLPID combination.
+
+   Strictly speaking, the routing state should not depend on the SID.
+   However, if the routing state is keyed only by (MRI, NSLP), there is
+   a trivial denial-of-service attack (see Section 8.3) where a
+   malicious off-path node asserts that it is the peer for a particular
+   flow.  Such an attack would not redirect the traffic but would
+   reroute the signalling.  Instead, the routing state is also
+   segregated between different SIDs, which means that the attacking
+   node can only disrupt a signalling session if it can guess the
+   corresponding SID.  Normative rules on the selection of SIDs are
+   given in Section 4.1.3.
+
+3.8.  Signalling Applications and NSLPIDs
+
+   The functionality for signalling applications is supported by NSIS
+   Signalling Layer Protocols (NSLPs).  Each NSLP is identified by a
+   16-bit NSLP identifier (NSLPID), assigned by IANA (Section 9).  A
+   single signalling application, such as resource reservation, may
+   define a family of NSLPs to implement its functionality, for example,
+   to carry out signalling operations at different levels in a hierarchy
+   (cf. [21]).  However, the interactions between the different NSLPs
+   (for example, to relate aggregation levels or aggregation region
+   boundaries in the resource management case) are handled at the
+   signalling application level; the NSLPID is the only information
+   visible to GIST about the signalling application being used.
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 16]
+
+RFC 5971                          GIST                      October 2010
+
+
+3.9.  GIST Security Services
+
+   GIST has two distinct security goals:
+
+   o  to protect GIST state from corruption, and to protect the nodes on
+      which it runs from resource exhaustion attacks; and
+
+   o  to provide secure transport for NSLP messages to the signalling
+      applications.
+
+   The protocol mechanisms to achieve the first goal are mainly internal
+   to GIST.  They include a cookie exchange and return routability check
+   to protect the handshake that sets up routing state, and a random SID
+   is also used to prevent off-path session hijacking by SID guessing.
+   Further details are given in Section 4.1.3 and Section 4.4.1, and the
+   overall security aspects are discussed in Section 8.
+
+   A second level of protection is provided by the use of a channel
+   security protocol in messaging associations (i.e., within C-mode).
+   This mechanism serves two purposes: to protect against on-path
+   attacks on GIST and to provide a secure channel for NSLP messages.
+   For the mechanism to be effective, it must be able to provide the
+   following functions:
+
+   o  mutual authentication of the GIST peer nodes;
+
+   o  ability to verify the authenticated identity against a database of
+      nodes authorised to take part in GIST signalling;
+
+   o  confidentiality and integrity protection for NSLP data, and
+      provision of the authenticated identities used to the signalling
+      application.
+
+   The authorised peer database is described in more detail in
+   Section 4.4.2, including the types of entries that it can contain and
+   the authorisation checking algorithm that is used.  The only channel
+   security protocol defined by this specification is a basic use of
+   TLS, and Section 5.7.3 defines the TLS-specific aspects of how these
+   functions (for example, authentication and identity comparison) are
+   integrated with the rest of GIST operation.  At a high level, there
+   are several alternative protocols with similar functionality, and the
+   handshake (Section 4.4.1) provides a mechanism within GIST to select
+   between them.  However, they differ in their identity schemes and
+   authentication methods and dependencies on infrastructure support for
+   the authentication process, and any GIST extension to incorporate
+   them would need to define the details of the corresponding
+   interactions with GIST operation.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 17]
+
+RFC 5971                          GIST                      October 2010
+
+
+3.10.  Example of Operation
+
+   This section presents an example of GIST usage in a relatively simple
+   (in particular, NAT-free) signalling scenario, to illustrate its main
+   features.
+
+               GN1                                      GN2
+          +------------+                           +------------+
+  NSLP    |            |                           |            |
+  Level   | >>>>>>>>>1 |                           | 5>>>>>>>>5 |
+          | ^        V |       Intermediate        | ^        V |
+          |-^--------2-|          Routers          |-^--------V-|
+          | ^        V |                           | ^        V |
+          | ^        V |    +-----+     +-----+    | ^        V |
+  >>>>>>>>>>^        >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5        5>>>>>>>>>
+          |            |    |     |     |     |    |            |
+  GIST    |          6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6          |
+  Level   +------------+    +-----+     +-----+    +------------+
+
+               >>>>>, <<<<< = Signalling messages
+               1 - 6        = Stages in the example
+                              (stages 7 and 8 are not shown)
+
+                      Figure 3: Example of Operation
+
+   Consider the case of an RSVP-like signalling application that makes
+   receiver-based resource reservations for a single unicast flow.  In
+   general, signalling can take place along the entire end-to-end path
+   (between flow source and destination), but the role of GIST is only
+   to transfer signalling messages over a single segment of the path,
+   between neighbouring resource-capable nodes.  Basic GIST operation is
+   the same, whether it involves the endpoints or only interior nodes:
+   in either case, GIST is triggered by a request from a local
+   signalling application.  The example here describes how GIST
+   transfers messages between two adjacent peers some distance along the
+   path, GN1 and GN2 (see Figure 3).  We take up the story at the point
+   where a message is being processed above the GIST layer by the
+   signalling application in GN1.
+
+   1.  The signalling application in GN1 determines that this message is
+       a simple description of resources that would be appropriate for
+       the flow.  It determines that it has no special security or
+       transport requirements for the message, but simply that it should
+       be transferred to the next downstream signalling application peer
+       on the path that the flow will take.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 18]
+
+RFC 5971                          GIST                      October 2010
+
+
+   2.  The message payload is passed to the GIST layer in GN1, along
+       with a definition of the flow and description of the message
+       transfer attributes (in this case, requesting no reliable
+       transmission or channel security protection).  GIST determines
+       that this particular message does not require fragmentation and
+       that it has no knowledge of the next peer for this flow and
+       signalling application; however, it also determines that this
+       application is likely to require secured upstream and downstream
+       transport of large messages in the future.  This determination is
+       a function of node-internal policy interactions between GIST and
+       the signalling application.
+
+   3.  GN1 therefore constructs a GIST Query carrying the NSLP payload,
+       and additional payloads at the GIST level which will be used to
+       initiate a messaging association.  The Query is encapsulated in a
+       UDP datagram and injected into the network.  At the IP level, the
+       destination address is the flow receiver, and an IP Router Alert
+       Option (RAO) is also included.
+
+   4.  The Query passes through the network towards the flow receiver,
+       and is seen by each router in turn.  GIST-unaware routers will
+       not recognise the RAO value and will forward the message
+       unchanged; GIST-aware routers that do not support the NSLP in
+       question will also forward the message basically unchanged,
+       although they may need to process more of the message to decide
+       this after initial interception.
+
+   5.  The message is intercepted at GN2.  The GIST layer identifies the
+       message as relevant to a local signalling application, and passes
+       the NSLP payload and flow description upwards to it.  This
+       signalling application in GN2 indicates to GIST that it will peer
+       with GN1 and so GIST should proceed to set up any routing state.
+       In addition, the signalling application continues to process the
+       message as in GN1 (compare step 1), passing the message back down
+       to GIST so that it is sent further downstream, and this will
+       eventually result in the message reaching the flow receiver.
+       GIST itself operates hop-by-hop, and the signalling application
+       joins these hops together to manage the end-to-end signalling
+       operations.
+
+   6.  In parallel, the GIST instance in GN2 now knows that it should
+       maintain routing state and a messaging association for future
+       signalling with GN1.  This is recognised because the message is a
+       Query, and because the local signalling application has indicated
+       that it will peer with GN1.  There are two possible cases for
+       sending back the necessary GIST Response:
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 19]
+
+RFC 5971                          GIST                      October 2010
+
+
+       6.A - Association Exists:  GN1 and GN2 already have an
+             appropriate MA.  GN2 simply records the identity of GN1 as
+             its upstream peer for that flow and NSLP, and sends a
+             Response back to GN1 over the MA identifying itself as the
+             peer for this flow.
+
+       6.B - No Association:  GN2 sends the Response in D-mode directly
+             to GN1, identifying itself and agreeing to the messaging
+             association setup.  The protocol exchanges needed to
+             complete this will proceed in parallel with the following
+             stages.
+
+       In each case, the result is that GN1 and GN2 are now in a peering
+       relationship for the flow.
+
+   7.  Eventually, another NSLP message works its way upstream from the
+       receiver to GN2.  This message contains a description of the
+       actual resources requested, along with authorisation and other
+       security information.  The signalling application in GN2 passes
+       this payload to the GIST level, along with the flow definition
+       and transfer attributes; in this case, it could request reliable
+       transmission and use of a secure channel for integrity
+       protection.  (Other combinations of attributes are possible.)
+
+   8.  The GIST layer in GN2 identifies the upstream peer for this flow
+       and NSLP as GN1, and determines that it has an MA with the
+       appropriate properties.  The message is queued on the MA for
+       transmission; this may incur some delay if the procedures begun
+       in step 6.B have not yet completed.
+
+   Further messages can be passed in each direction in the same way.
+   The GIST layer in each node can in parallel carry out maintenance
+   operations such as route change detection (see Section 7.1).
+
+   It should be understood that several of these details of GIST
+   operations can be varied, either by local policy or according to
+   signalling application requirements.  The authoritative details are
+   contained in the remainder of this document.
+
+4.  GIST Processing Overview
+
+   This section defines the basic structure and operation of GIST.
+   Section 4.1 describes the way in which GIST interacts with local
+   signalling applications in the form of an abstract service interface.
+   Section 4.2 describes the per-flow and per-peer state that GIST
+   maintains for the purpose of transferring messages.  Section 4.3
+   describes how messages are processed in the case where any necessary
+   messaging associations and routing state already exist; this includes
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 20]
+
+RFC 5971                          GIST                      October 2010
+
+
+   the simple scenario of pure D-mode operation, where no messaging
+   associations are necessary.  Finally, Section 4.4 describes how
+   routing state and messaging associations are created and managed.
+
+4.1.  GIST Service Interface
+
+   This section describes the interaction between GIST and signalling
+   applications in terms of an abstract service interface, including a
+   definition of the attributes of the message transfer that GIST can
+   offer.  The service interface presented here is non-normative and
+   does not constrain actual implementations of any interface between
+   GIST and signalling applications; the interface is provided to aid
+   understanding of how GIST can be used.  However, requirements on SID
+   selection and internal GIST behaviour to support message transfer
+   semantics (such as in-order delivery) are stated normatively here.
+
+   The same service interface is presented at every GIST node; however,
+   applications may invoke it differently at different nodes, depending
+   for example on local policy.  In addition, the service interface is
+   defined independently of any specific transport protocol, or even the
+   distinction between D-mode and C-mode.  The initial version of this
+   specification defines how to support the service interface using a
+   C-mode based on TCP; if additional protocol support is added, this
+   will support the same interface and so the change will be invisible
+   to applications, except as a possible performance improvement.  A
+   more detailed description of this service interface is given in
+   Appendix B.
+
+4.1.1.  Message Handling
+
+   Fundamentally, GIST provides a simple message-by-message transfer
+   service for use by signalling applications: individual messages are
+   sent, and individual messages are received.  At the service
+   interface, the NSLP payload, which is opaque to GIST, is accompanied
+   by control information expressing the application's requirements
+   about how the message should be routed (the MRI), and the application
+   also provides the session identifier (SID); see Section 4.1.3.
+   Additional message transfer attributes control the specific transport
+   and security properties that the signalling application desires.
+
+   The distinction between GIST D- and C-mode is not visible at the
+   service interface.  In addition, the functionality to handle
+   fragmentation and reassembly, bundling together of small messages for
+   efficiency, and congestion control are not visible at the service
+   interface; GIST will take whatever action is necessary based on the
+   properties of the messages and local node state.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 21]
+
+RFC 5971                          GIST                      October 2010
+
+
+   A signalling application is free to choose the rate at which it
+   processes inbound messages; an implementation MAY allow the
+   application to block accepting messages from GIST.  In these
+   circumstances, GIST MAY discard unreliably delivered messages, but
+   for reliable messages MUST propagate flow-control condition back to
+   the sender.  Therefore, applications must be aware that they may in
+   turn be blocked from sending outbound messages themselves.
+
+4.1.2.  Message Transfer Attributes
+
+   Message transfer attributes are used by NSLPs to define minimum
+   required levels of message processing.  The attributes available are
+   as follows:
+
+   Reliability:  This attribute may be 'true' or 'false'.  When 'true',
+      the following rules apply:
+
+      *  messages MUST be delivered to the signalling application in the
+         peer exactly once or not at all;
+
+      *  for messages with the same SID, the delivery MUST be in order;
+
+      *  if there is a chance that the message was not delivered (e.g.,
+         in the case of a transport layer error), an error MUST be
+         indicated to the local signalling application identifying the
+         routing information for the message in question.
+
+      GIST implements reliability by using an appropriate transport
+      protocol within a messaging association, so mechanisms for the
+      detection of message loss depend on the protocol in question; for
+      the current specification, the case of TCP is considered in
+      Section 5.7.2.  When 'false', a message may be delivered, once,
+      several times, or not at all, with no error indications in any of
+      these cases.
+
+   Security:  This attribute defines the set of security properties that
+      the signalling application requires for the message, including the
+      type of protection required, and what authenticated identities
+      should be used for the signalling source and destination.  This
+      information maps onto the corresponding properties of the security
+      associations established between the peers in C-mode.  Keying
+      material for the security associations is established by the
+      authentication mechanisms within the messaging association
+      protocols themselves; see Section 8.2.  The attribute can be
+      specified explicitly by the signalling application, or reported by
+      GIST to the signalling application.  The latter can take place
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 22]
+
+RFC 5971                          GIST                      October 2010
+
+
+      either on receiving a message, or just before sending a message
+      but after configuring or selecting the messaging association to be
+      used for it.
+
+      This attribute can also be used to convey information about any
+      address validation carried out by GIST, such as whether a return
+      routability check has been carried out.  Further details are
+      discussed in Appendix B.
+
+   Local Processing:  An NSLP may provide hints to GIST to enable more
+      efficient or appropriate processing.  For example, the NSLP may
+      select a priority from a range of locally defined values to
+      influence the sequence in which messages leave a node.  Any
+      priority mechanism MUST respect the ordering requirements for
+      reliable messages within a session, and priority values are not
+      carried in the protocol or available at the signalling peer or
+      intermediate nodes.  An NSLP may also indicate that upstream path
+      routing state will not be needed for this flow, to inhibit the
+      node requesting its downstream peer to create it; conversely, even
+      if routing state exists, the NSLP may request that it is not used,
+      which will lead to GIST Data messages being sent Q-mode
+      encapsulated instead.
+
+   A GIST implementation MAY deliver messages with stronger attribute
+   values than those explicitly requested by the application.
+
+4.1.3.  SID Selection
+
+   The fact that SIDs index routing state (see Section 4.2.1 below)
+   means that there are requirements for how they are selected.
+   Specifically, signalling applications MUST choose SIDs so that they
+   are cryptographically random, and SHOULD NOT use several SIDs for the
+   same flow, to avoid additional load from routing state maintenance.
+   Guidance on secure randomness generation can be found in [31].
+
+4.2.  GIST State
+
+4.2.1.  Message Routing State
+
+   For each flow, the GIST layer can maintain message routing state to
+   manage the processing of outgoing messages.  This state is
+   conceptually organised into a table with the following structure.
+   Each row in the table corresponds to a unique combination of the
+   following three items:
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 23]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Message Routing Information (MRI):  This defines the method to be
+      used to route the message, the direction in which to send the
+      message, and any associated addressing information; see
+      Section 3.3.
+
+   Session Identifier (SID):  The signalling session with which this
+      message should be associated; see Section 3.7.
+
+   NSLP Identifier (NSLPID):  This is an IANA-assigned identifier
+      associated with the NSLP that is generating messages for this
+      flow; see Section 3.8.  The inclusion of this identifier allows
+      the routing state to be different for different NSLPs.
+
+   The information associated with a given MRI/SID/NSLPID combination
+   consists of the routing state to reach the peer in the direction
+   given by the MRI.  For any flow, there will usually be two entries in
+   the table, one each for the upstream and downstream MRI.  The routing
+   state includes information about the peer identity (see
+   Section 4.4.3), and a UDP port number for D-mode, or a reference to
+   one or more MAs for C-mode.  Entries in the routing state table are
+   created by the GIST handshake, which is described in more detail in
+   Section 4.4.
+
+   It is also possible for the state information for either direction to
+   be empty.  There are several possible cases:
+
+   o  The signalling application has indicated that no messages will
+      actually be sent in that direction.
+
+   o  The node is the endpoint of the signalling path, for example,
+      because it is acting as a proxy, or because it has determined that
+      there are no further signalling nodes in that direction.
+
+   o  The node is using other techniques to route the message.  For
+      example, it can send it in Q-mode and rely on the peer to
+      intercept it.
+
+   In particular, if the node is a flow endpoint, GIST will refuse to
+   create routing state for the direction beyond the end of the flow
+   (see Section 4.3.3).  Each entry in the routing state table has an
+   associated validity timer indicating for how long it can be
+   considered accurate.  When this timer expires, the entry MUST be
+   purged if it has not been refreshed.  Installation and maintenance of
+   routing state are described in more detail in Section 4.4.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 24]
+
+RFC 5971                          GIST                      October 2010
+
+
+4.2.2.  Peer-Peer Messaging Association State
+
+   The per-flow message routing state is not the only state stored by
+   GIST.  There is also the state required to manage the MAs.  Since
+   these are not per-flow, they are stored separately from the routing
+   state, including the following per-MA information:
+
+   o  a queue of any messages that require the use of an MA, pending
+      transmission while the MA is being established;
+
+   o  the time since the peer re-stated its desire to keep the MA open
+      (see Section 4.4.5).
+
+   In addition, per-MA state, such as TCP port numbers or timer
+   information, is held in the messaging association protocols
+   themselves.  However, the details of this state are not directly
+   visible to GIST, and they do not affect the rest of the protocol
+   description.
+
+4.3.  Basic GIST Message Processing
+
+   This section describes how signalling application messages are
+   processed in the case where any necessary messaging associations and
+   routing state are already in place.  The description is divided into
+   several parts.  First, message reception, local processing, and
+   message transmission are described for the case where the node hosts
+   the NSLPID identified in the message.  Second, in Section 4.3.4, the
+   case where the message is handled directly in the IP or GIST layer
+   (because there is no matching signalling application on the node) is
+   given.  An overview is given in Figure 4.  This section concentrates
+   on the GIST-level processing, with full details of IP and transport
+   layer encapsulation in Section 5.3 and Section 5.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 25]
+
+RFC 5971                          GIST                      October 2010
+
+
+       +---------------------------------------------------------+
+       |        >>  Signalling Application Processing   >>       |
+       |                                                         |
+       +--------^---------------------------------------V--------+
+                ^ NSLP                             NSLP V
+                ^ Payloads                     Payloads V
+       +--------^---------------------------------------V--------+
+       |                    >>    GIST    >>                     |
+       |  ^           ^  ^     Processing      V  V           V  |
+       +--x-----------N--Q---------------------Q--N-----------x--+
+          x           N  Q                     Q  N           x
+          x           N  Q>>>>>>>>>>>>>>>>>>>>>Q  N           x
+          x           N  Q      Bypass at      Q  N           x
+       +--x-----+  +--N--Q--+  GIST level   +--Q--N--+  +-----x--+
+       | C-mode |  | D-mode |               | D-mode |  | C-mode |
+       |Handling|  |Handling|               |Handling|  |Handling|
+       +--x-----+  +--N--Q--+               +--Q--N--+  +-----x--+
+          x          N   Q                     Q   N          x
+          x    NNNNNN    Q>>>>>>>>>>>>>>>>>>>>>Q    NNNNNN    x
+          x   N          Q      Bypass at      Q          N   x
+       +--x--N--+  +-----Q--+  IP (router   +--Q-----+  +--N--x--+
+       |IP Host |  | Q-mode |  alert) level | Q-mode |  |IP Host |
+       |Handling|  |Handling|               |Handling|  |Handling|
+       +--x--N--+  +-----Q--+               +--Q-----+  +--N--x--+
+          x  N           Q                     Q           N  x
+       +--x--N-----------Q--+               +--Q-----------N--x--+
+       |      IP Layer      |               |      IP Layer      |
+       |   (Receive Side)   |               |  (Transmit Side)   |
+       +--x--N-----------Q--+               +--Q-----------N--x--+
+          x  N           Q                     Q           N  x
+          x  N           Q                     Q           N  x
+
+        NNNNNNNNNNNNNN = Normal D-mode messages
+        QQQQQQQQQQQQQQ = D-mode messages that are Q-mode encapsulated
+        xxxxxxxxxxxxxx = C-mode messages
+                       RAO = Router Alert Option
+
+                Figure 4: Message Paths through a GIST Node
+
+4.3.1.  Message Reception
+
+   Messages can be received in C-mode or D-mode.
+
+   Reception in C-mode is simple: incoming packets undergo the security
+   and transport treatment associated with the MA, and the MA provides
+   complete messages to the GIST layer for further processing.
+
+   Reception in D-mode depends on the message type.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 26]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Normal encapsulation:  Normal messages arrive UDP-encapsulated and
+      addressed directly to the receiving signalling node, at an address
+      and port learned previously.  Each datagram contains a single
+      message, which is passed to the GIST layer for further processing,
+      just as in the C-mode case.
+
+   Q-mode encapsulation:  Where GIST is sending messages to be
+      intercepted by the appropriate peer rather than directly addressed
+      to it (in particular, Query messages), these are UDP encapsulated,
+      and MAY include an IP Router Alert Option (RAO) if required by the
+      MRM.  Each GIST node can therefore see every such message, but
+      unless the message exactly matches the Q-mode encapsulation rules
+      (Section 5.3.2) it MUST be forwarded transparently at the IP
+      level.  If it does match, GIST MUST check the NSLPID in the common
+      header.  The case where the NSLPID does not match a local
+      signalling application at all is considered below in
+      Section 4.3.4; otherwise, the message MUST be passed up to the
+      GIST layer for further processing.
+
+   Several different RAO values may be used by the NSIS protocol suite.
+   GIST itself does not allocate any RAO values (for either IPv4 or
+   IPv6); an assignment is made for each NSLP using MRMs that use the
+   RAO in the Q-mode encapsulation.  The assignment rationale is
+   discussed in a separate document [12].  The RAO value assigned for an
+   NSLPID may be different for IPv4 and IPv6.  Note the different
+   significance between the RAO and the NSLPID values: the meaning of a
+   message (which signalling application it refers to, whether it should
+   be processed at a node) is determined only from the NSLPID; the role
+   of the RAO value is simply to allow nodes to pre-filter which IP
+   datagrams are analysed to see if they might be Q-mode GIST messages.
+
+   For all assignments associated with NSIS, the RAO-specific processing
+   is the same and is as defined by this specification, here and in
+   Section 4.3.4 and Section 5.3.2.
+
+   Immediately after reception, the GIST hop count is checked.  Any
+   message with a GIST hop count of zero MUST be rejected with a "Hop
+   Limit Exceeded" error message (Appendix A.4.4.2); note that a correct
+   GIST implementation will never send a message with a GIST hop count
+   of zero.  Otherwise, the GIST hop count MUST be decremented by one
+   before the next stage.
+
+4.3.2.  Local Processing and Validation
+
+   Once a message has been received, it is processed locally within the
+   GIST layer.  Further processing depends on the message type and
+   payloads carried; most of the GIST payloads are associated with
+   internal state maintenance, and details are covered in Section 4.4.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 27]
+
+RFC 5971                          GIST                      October 2010
+
+
+   This section concentrates on the interaction with the signalling
+   application, in particular, the decision to peer and how data is
+   delivered to the NSLP.
+
+   In the case of a Query, there is an interaction with the signalling
+   application to determine which of two courses to follow.  The first
+   option (peering) MUST be chosen if the node is the final destination
+   of the Query message.
+
+   1.  The receiving signalling application wishes to become a
+       signalling peer with the Querying node.  GIST MUST continue with
+       the handshake process to set up message routing state, as
+       described in Section 4.4.1.  The application MAY provide an NSLP
+       payload for the same NSLPID, which GIST will transfer in the
+       Response.
+
+   2.  The signalling application does not wish to set up state with the
+       Querying node and become its peer.  This includes the case where
+       a node wishes to avoid taking part in the signalling for overload
+       protection reasons.  GIST MUST propagate the Query, similar to
+       the case described in Section 4.3.4.  No message is sent back to
+       the Querying node.  The application MAY provide an updated NSLP
+       payload for the same NSLPID, which will be used in the Query
+       forwarded by GIST.  Note that if the node that finally processes
+       the Query returns an Error message, this will be sent directly
+       back to the originating node, bypassing any forwarders.  For
+       these diagnostics to be meaningful, any GIST node forwarding a
+       Query, or relaying it with modified NSLP payload, MUST NOT modify
+       it except in the GIST hop count; in particular, it MUST NOT
+       modify any other GIST payloads or their order.  An implementation
+       MAY choose to achieve this by retaining the original message,
+       rather than reconstructing it from some parsed internal
+       representation.
+
+   This interaction with the signalling application, including the
+   generation or update of an NSLP payload, SHOULD take place
+   synchronously as part of the Query processing.  In terms of the GIST
+   service interface, this can be implemented by providing appropriate
+   return values for the primitive that is triggered when such a message
+   is received; see Appendix B.2 for further discussion.
+
+   For all GIST message types other than Queries, if the message
+   includes an NSLP payload, this MUST be delivered locally to the
+   signalling application identified by the NSLPID.  The format of the
+   payload is not constrained by GIST, and the content is not
+   interpreted.  Delivery is subject to the following validation checks,
+   which MUST be applied in the sequence given:
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 28]
+
+RFC 5971                          GIST                      October 2010
+
+
+   1.  if the message was explicitly routed (see Section 7.1.5) or is a
+       Data message delivered without routing state (see Section 5.3.2),
+       the payload is delivered but flagged to the receiving NSLP to
+       indicate that routing state was not validated;
+
+   2.  else, if the message arrived on an association that is not
+       associated with the MRI/NSLPID/SID combination given in the
+       message, the message MUST be rejected with an "Incorrectly
+       Delivered Message" error message (Appendix A.4.4.4);
+
+   3.  else, if there is no routing state for this MRI/SID/NSLPID
+       combination, the message MUST either be dropped or be rejected
+       with an error message (see Section 4.4.6 for further details);
+
+   4.  else, the payload is delivered as normal.
+
+4.3.3.  Message Transmission
+
+   Signalling applications can generate their messages for transmission,
+   either asynchronously or in reply to an input message delivered by
+   GIST, and GIST can also generate messages autonomously.  GIST MUST
+   verify that it is not the direct destination of an outgoing message,
+   and MUST reject such messages with an error indication to the
+   signalling application.  When the message is generated by a
+   signalling application, it may be carried in a Query if local policy
+   and the message transfer attributes allow it; otherwise, this may
+   trigger setup of an MA over which the NSLP payload is sent in a Data
+   message.
+
+   Signalling applications may specify a value to be used for the GIST
+   hop count; otherwise, GIST selects a value itself.  GIST MUST reject
+   messages for which the signalling application has specified a value
+   of zero.  Although the GIST hop count is only intended to control
+   message looping at the GIST level, the GIST API (Appendix B) provides
+   the incoming hop count to the NSLPs, which can preserve it on
+   outgoing messages as they are forwarded further along the path.  This
+   provides a lightweight loop-control mechanism for NSLPs that do not
+   define anything more sophisticated.  Note that the count will be
+   decremented on forwarding through every GIST-aware node.  Initial
+   values for the GIST hop count are an implementation matter; one
+   suitable approach is to use the same algorithm as for IP TTL setting
+   [1].
+
+   When a message is available for transmission, GIST uses internal
+   policy and the stored routing state to determine how to handle it.
+   The following processing applies equally to locally generated
+   messages and messages forwarded from within the GIST or signalling
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 29]
+
+RFC 5971                          GIST                      October 2010
+
+
+   application levels.  However, see Section 5.6 for special rules
+   applying to the transmission of Error messages by GIST.
+
+   The main decision is whether the message must be sent in C-mode or
+   D-mode.  Reasons for using C-mode are:
+
+   o  message transfer attributes: for example, the signalling
+      application has specified security attributes that require
+      channel-secured delivery, or reliable delivery.
+
+   o  message size: a message whose size (including the GIST header,
+      GIST objects and any NSLP payload, and an allowance for the IP and
+      transport layer encapsulation required by D-mode) exceeds a
+      fragmentation-related threshold MUST be sent over C-mode, using a
+      messaging association that supports fragmentation and reassembly
+      internally.  The allowance for IP and transport layer
+      encapsulation is 64 bytes.  The message size MUST NOT exceed the
+      Path MTU to the next peer, if this is known.  If this is not
+      known, the message size MUST NOT exceed the least of the first-hop
+      MTU, and 576 bytes.  The same limit applies to IPv4 and IPv6.
+
+   o  congestion control: D-mode SHOULD NOT be used for signalling where
+      it is possible to set up routing state and use C-mode, unless the
+      network can be engineered to guarantee capacity for D-mode traffic
+      within the rate control limits imposed by GIST (see
+      Section 5.3.3).
+
+   In principle, as well as determining that some messaging association
+   must be used, GIST MAY select between a set of alternatives, e.g.,
+   for load sharing or because different messaging associations provide
+   different transport or security attributes.  For the case of reliable
+   delivery, GIST MUST NOT distribute messages for the same session over
+   multiple messaging associations in parallel, but MUST use a single
+   association at any given time.  The case of moving over to a new
+   association is covered in Section 4.4.5.
+
+   If the use of a messaging association (i.e., C-mode) is selected, the
+   message is queued on the association found from the routing state
+   table, and further output processing is carried out according to the
+   details of the protocol stacks used.  If no appropriate association
+   exists, the message is queued while one is created (see
+   Section 4.4.1), which will trigger the exchange of additional GIST
+   messages.  If no association can be created, this is an error
+   condition, and should be indicated back to the local signalling
+   application.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 30]
+
+RFC 5971                          GIST                      October 2010
+
+
+   If a messaging association is not appropriate, the message is sent in
+   D-mode.  The processing in this case depends on the message type,
+   local policy, and whether or not routing state exists.
+
+   o  If the message is not a Query, and local policy does not request
+      the use of Q-mode for this message, and routing state exists, it
+      is sent with the normal D-mode encapsulation directly to the
+      address from the routing state table.
+
+   o  If the message is a Query, or the message is Data and local policy
+      as given by the message transfer attributes requests the use of
+      Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the
+      details depend on the message routing method.
+
+   o  If no routing state exists, GIST can attempt to use Q-mode as in
+      the Query case: either sending a Data message with the Q-mode
+      encapsulation or using the event as a trigger for routing state
+      setup (see Section 4.4).  If this is not possible, e.g., because
+      the encapsulation for the MRM is only defined for one message
+      direction, then this is an error condition that is reported back
+      to the local signalling application.
+
+4.3.4.  Nodes not Hosting the NSLP
+
+   A node may receive messages where it has no signalling application
+   corresponding to the message NSLPID.  There are several possible
+   cases depending mainly on the encapsulation:
+
+   1.  A message contains an RAO value that is relevant to NSIS, but it
+       does not exactly match the Q-mode encapsulation rules of
+       Section 5.3.2.  The message MUST be transparently forwarded at
+       the IP layer.  See Section 3.6.
+
+   2.  A Q-mode encapsulated message contains an RAO value that has been
+       assigned to some NSIS signalling application but that is not used
+       on this specific node, but the IP layer is unable to distinguish
+       whether it needs to be passed to GIST for further processing or
+       whether the packet should be forwarded just like a normal IP
+       datagram.
+
+   3.  A Q-mode encapsulated message contains an RAO value that has been
+       assigned to an NSIS signalling application that is used on this
+       node, but the signalling application does not process the NSLPID
+       in the message.  (This covers the case where a signalling
+       application uses a set of NSLPIDs.)
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 31]
+
+RFC 5971                          GIST                      October 2010
+
+
+   4.  A directly addressed message (in D-mode or C-mode) is delivered
+       to a node for which there is no corresponding signalling
+       application.  With the current specification, this should not
+       happen in normal operation.  While future versions might find a
+       use for such a feature, currently this MUST cause an "Unknown
+       NSLPID" error message (Appendix A.4.4.6).
+
+   5.  A Q-mode encapsulated message arrives at the end-system that does
+       not handle the signalling application.  This is possible in
+       normal operation, and MUST be indicated to the sender with an
+       "Endpoint Found" informational message (Appendix A.4.4.7).  The
+       end-system includes the MRI and SID from the original message in
+       the error message without interpreting them.
+
+   6.  The node is a GIST-aware NAT.  See Section 7.2.
+
+   In case (2) and (3), the role of GIST is to forward the message
+   essentially as though it were a normal IP datagram, and it will not
+   become a peer to the node sending the message.  Forwarding with
+   modified NSLP payloads is covered above in Section 4.3.2.  However, a
+   GIST implementation MUST ensure that the IP-layer TTL field and GIST
+   hop count are managed correctly to prevent message looping, and this
+   should be done consistently independently of where in the packet
+   processing path the decision is made.  The rules are that in cases
+   (2) and (3), the IP-layer TTL MUST be decremented just as if the
+   message was a normal IP forwarded packet.  In case (3), the GIST hop
+   count MUST be decremented as in the case of normal input processing,
+   which also applies to cases (4) and (5).
+
+   A GIST node processing Q-mode encapsulated messages in this way
+   SHOULD make the routing decision based on the full contents of the
+   MRI and not only the IP destination address.  It MAY also apply a
+   restricted set of sanity checks and under certain conditions return
+   an error message rather than forward the message.  These conditions
+   are:
+
+   1.  The message is so large that it would be fragmented on downstream
+       links, for example, because the downstream MTU is abnormally
+       small (less than 576 bytes).  The error "Message Too Large"
+       (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD
+       begin messaging association setup.
+
+   2.  The GIST hop count has reached zero.  The error "Hop Limit
+       Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender,
+       which MAY retry with a larger initial hop count.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 32]
+
+RFC 5971                          GIST                      October 2010
+
+
+   3.  The MRI represents a flow definition that is too general to be
+       forwarded along a unique path (e.g., the destination address
+       prefix is too short).  The error "MRI Validation Failure"
+       (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be
+       returned to the sender, which MAY retry with restricted MRIs,
+       possibly starting additional signalling sessions to do so.  If
+       the GIST node does not understand the MRM in question, it MUST
+       NOT apply this check, instead forwarding the message
+       transparently.
+
+   In the first two cases, only the common header of the GIST message is
+   examined; in the third case, the MRI is also examined.  The rest of
+   the message MUST NOT be inspected in any case.  Similar to the case
+   of Section 4.3.2, the GIST payloads MUST NOT be modified or re-
+   ordered; an implementation MAY choose to achieve this by retaining
+   the original message, rather than reconstructing it from some parsed
+   internal representation.
+
+4.4.  Routing State and Messaging Association Maintenance
+
+   The main responsibility of GIST is to manage the routing state and
+   messaging associations that are used in the message processing
+   described above.  Routing state is installed and refreshed by GIST
+   handshake messages.  Messaging associations are set up by the normal
+   procedures of the transport and security protocols that comprise
+   them, using peer IP addresses from the routing state.  Once a
+   messaging association has been created, its refresh and expiration
+   can be managed independently from the routing state.
+
+   There are two different cases for state installation and refresh:
+
+   1.  Where routing state is being discovered or a new association is
+       to be established; and
+
+   2.  Where a suitable association already exists, including the case
+       where routing state for the flow is being refreshed.
+
+   These cases are now considered in turn, followed by the case of
+   background general management procedures.
+
+4.4.1.  Routing State and Messaging Association Creation
+
+   The message sequence for GIST state setup between peers is shown in
+   Figure 5 and described in detail below.  The figure informally
+   summarises the contents of each message, including optional elements
+   in square brackets.  An example is given in Appendix D.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 33]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The first message in any routing state maintenance operation is a
+   Query, sent from the Querying node and intercepted at the responding
+   node.  This message has addressing and other identifiers appropriate
+   for the flow and signalling application that state maintenance is
+   being done for, addressing information about the node that generated
+   the Query itself, and MAY contain an NSLP payload.  It also includes
+   a Query-Cookie, and optionally capability information about messaging
+   association protocol stacks.  The role of the cookies in this and
+   later messages is to protect against certain denial-of-service
+   attacks and to correlate the events in the message sequence (see
+   Section 8.5 for further details).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 34]
+
+RFC 5971                          GIST                      October 2010
+
+
+            +----------+                     +----------+
+            | Querying |                     |Responding|
+            | Node(Q-N)|                     | Node(R-N)|
+            +----------+                     +----------+
+                               Query                  .............
+                       ---------------------->        .           .
+                       Router Alert Option            .  Routing  .
+                       MRI/SID/NSLPID                 .   state   .
+                       Q-N Network Layer Info         . installed .
+                       Query-Cookie                   .    at     .
+                       [Q-N Stack-Proposal            . Responding.
+                        Q-N Stack-Config-Data]        .    node   .
+                       [NSLP Payload]                 .  (case 1) .
+                                                      .............
+               ......................................
+               .  The responder can use an existing .
+               . messaging association if available .
+               . from here onwards to short-circuit .
+               .     messaging association setup    .
+               ......................................
+
+                             Response
+   .............       <----------------------
+   .  Routing  .       MRI/SID/NSLPID
+   .   state   .       R-N Network Layer Info
+   . installed .       Query-Cookie
+   .    at     .       [Responder-Cookie
+   .  Querying .        [R-N Stack-Proposal
+   .   node    .         R-N Stack-Config-Data]]
+   .............       [NSLP Payload]
+
+                ....................................
+                . If a messaging association needs .
+                . to be created, it is set up here .
+                .     and the Confirm uses it      .
+                ....................................
+
+                           Confirm                    .............
+                     ---------------------->          .  Routing  .
+                     MRI/SID/NSLPID                   .   state   .
+                     Q-N Network Layer Info           . installed .
+                     [Responder-Cookie                .    at     .
+                      [R-N Stack-Proposal             . Responding.
+                       [Q-N Stack-Config-Data]]]      .    node   .
+                     [NSLP Payload]                   .  (case 2) .
+                                                      .............
+
+                 Figure 5: Message Sequence at State Setup
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 35]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Provided that the signalling application has indicated that message
+   routing state should be set up (see Section 4.3.2), reception of a
+   Query MUST elicit a Response.  This is a normally encapsulated D-mode
+   message with additional GIST payloads.  It contains network layer
+   information about the Responding node, echoes the Query-Cookie, and
+   MAY contain an NSLP payload, possibly a reply to the NSLP payload in
+   the initial message.  In case a messaging association was requested,
+   it MUST also contain a Responder-Cookie and its own capability
+   information about messaging association protocol stacks.  Even if a
+   messaging association is not requested, the Response MAY still
+   include a Responder-Cookie if the node's routing state setup policy
+   requires it (see below).
+
+   Setup of a new messaging association begins when peer addressing
+   information is available and a new messaging association is actually
+   needed.  Any setup MUST take place immediately after the specific
+   Query/Response exchange, because the addressing information used may
+   have a limited lifetime, either because it depends on limited
+   lifetime NAT bindings or because it refers to agile destination ports
+   for the transport protocols.  The Stack-Proposal and Stack-
+   Configuration-Data objects carried in the exchange carry capability
+   information about what messaging association protocols can be used,
+   and the processing of these objects is described in more detail in
+   Section 5.7.  With the protocol options currently defined, setup of
+   the messaging association always starts from the Querying node,
+   although more flexible configurations are possible within the overall
+   GIST design.  If the messaging association includes a channel
+   security protocol, each GIST node MUST verify the authenticated
+   identity of the peer against its authorised peer database, and if
+   there is no match the messaging association MUST be torn down.  The
+   database and authorisation check are described in more detail in
+   Section 4.4.2 below.  Note that the verification can depend on what
+   the MA is to be used for (e.g., for which MRI or session), so this
+   step may not be possible immediately after authentication has
+   completed but some time later.
+
+   Finally, after any necessary messaging association setup has
+   completed, a Confirm MUST be sent if the Response requested it.  Once
+   the Confirm has been sent, the Querying node assumes that routing
+   state has been installed at the responder, and can send normal Data
+   messages for the flow in question; recovery from a lost Confirm is
+   discussed in Section 5.3.3.  If a messaging association is being
+   used, the Confirm MUST be sent over it before any other messages for
+   the same flow, and it echoes the Responder-Cookie and Stack-Proposal
+   from the Response.  The former is used to allow the receiver to
+   validate the contents of the message (see Section 8.5), and the
+   latter is to prevent certain bidding-down attacks on messaging
+   association security (see Section 8.6).  This first Confirm on a new
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 36]
+
+RFC 5971                          GIST                      October 2010
+
+
+   association MUST also contain a Stack-Configuration-Data object
+   carrying an MA-Hold-Time value, which supersedes the value given in
+   the original Query.  The association can be used in the upstream
+   direction for the MRI and NSLPID carried in the Confirm, after the
+   Confirm has been received.
+
+   The Querying node MUST install the responder address, derived from
+   the R-Node Network Layer info, as routing state information after
+   verifying the Query-Cookie in the Response.  The Responding node MAY
+   install the querying address as peer state information at two points
+   in time:
+
+   Case 1:  after the receipt of the initial Query, or
+
+   Case 2:  after a Confirm containing the Responder-Cookie.
+
+   The Responding node SHOULD derive the peer address from the Q-Node
+   Network Layer Info if this was decoded successfully.  Otherwise, it
+   MAY be derived from the IP source address of the message if the
+   common header flags this as being the signalling source address.  The
+   precise constraints on when state information is installed are a
+   matter of security policy considerations on prevention of denial-of-
+   service attacks and state poisoning attacks, which are discussed
+   further in Section 8.  Because the Responding node MAY choose to
+   delay state installation as in case (2), the Confirm must contain
+   sufficient information to allow it to be processed in the same way as
+   the original Query.  This places some special requirements on NAT
+   traversal and cookie functionality, which are discussed in
+   Section 7.2 and Section 8 respectively.
+
+4.4.2.  GIST Peer Authorisation
+
+   When two GIST nodes authenticate using a messaging association, both
+   ends have to decide whether to accept the creation of the MA and
+   whether to trust the information sent over it.  This can be seen as
+   an authorisation decision:
+
+   o  Authorised peers are trusted to install correct routing state
+      about themselves and not, for example, to claim that they are on-
+      path for a flow when they are not.
+
+   o  Authorised peers are trusted to obey transport- and application-
+      level flow control rules, and not to attempt to create overload
+      situations.
+
+   o  Authorised peers are trusted not to send erroneous or malicious
+      error messages, for example, asserting that routing state has been
+      lost when it has not.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 37]
+
+RFC 5971                          GIST                      October 2010
+
+
+   This specification models the decision as verification by the
+   authorising node of the peer's identity against a local list of
+   peers, the authorised peer database (APD).  The APD is an abstract
+   construct, similar to the security policy database of IPsec [36].
+   Implementations MAY provide the associated functionality in any way
+   they choose.  This section defines only the requirements for APD
+   administration and the consequences of successfully validating a
+   peer's identity against it.
+
+   The APD consists of a list of entries.  Each entry includes an
+   identity, the namespace from which the identity comes (e.g., DNS
+   domains), the scope within which the entry is applicable, and whether
+   authorisation is allowed or denied.  The following are example
+   scopes:
+
+   Peer Address Ownership:  The scope is the IP address at which the
+      peer for this MRI should be; the APD entry denotes the identity as
+      the owner of address.  If the authorising node can determine this
+      address from local information (such as its own routing tables),
+      matching this entry shows that the peer is the correct on-path
+      node and so should be authorised.  The determination is simple if
+      the peer is one IP hop downstream, since the IP address can be
+      derived from the router's forwarding tables.  If the peer is more
+      than one hop away or is upstream, the determination is harder but
+      may still be possible in some circumstances.  The authorising node
+      may be able to determine a (small) set of possible peer addresses,
+      and accept that any of these could be the correct peer.
+
+   End-System Subnet:  The scope is an address range within which the
+      MRI source or destination lies; the APD entry denotes the identity
+      as potentially being on-path between the authorising node and that
+      address range.  There may be different source and destination
+      scopes, to account for asymmetric routing.
+
+   The same identity may appear in multiple entries, and the order of
+   entries in the APD is significant.  When a messaging association is
+   authenticated and associated with an MRI, the authorising node scans
+   the APD to find the first entry where the identity matches that
+   presented by the peer, and where the scope information matches the
+   circumstances for which the MA is being set up.  The identity
+   matching process itself depends on the messaging association protocol
+   that carries out the authentication, and details for TLS are given in
+   Section 5.7.3.  Whenever the full set of possible peers for a
+   specific scope is known, deny entries SHOULD be added for the
+   wildcard identity to reject signalling associations from unknown
+   nodes.  The ability of the authorising node to reject inappropriate
+   MAs depends directly on the granularity of the APD and the precision
+   of the scope matching process.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 38]
+
+RFC 5971                          GIST                      October 2010
+
+
+   If authorisation is allowed, the MA can be used as normal; otherwise,
+   it MUST be torn down without further GIST exchanges, and any routing
+   state associated with the MA MUST also be deleted.  An error
+   condition MAY be logged locally.  When an APD entry is modified or
+   deleted, the node MUST re-validate existing MAs and the routing state
+   table against the revised contents of the APD.  This may result in
+   MAs being torn down or routing state entries being deleted.  These
+   changes SHOULD be indicated to local signalling applications via the
+   NetworkNotification API call (Appendix B.4).
+
+   This specification does not define how the APD is populated.  As a
+   minimum, an implementation MUST provide an administrative interface
+   through which entries can be added, modified, or deleted.  More
+   sophisticated mechanisms are possible in some scenarios.  For
+   example, the fact that a node is legitimately associated with a
+   specific IP address could be established by direct embedding of the
+   IP address as a particular identity type in a certificate, or by a
+   mapping that address to another identifier type via an additional
+   database lookup (such as relating IP addresses in in-addr.arpa to
+   domain names).  An enterprise network operator could generate a list
+   of all the identities of its border nodes as authorised to be on the
+   signalling path to external destinations, and this could be
+   distributed to all hosts inside the network.  Regardless of the
+   technique, it MUST be ensured that the source data justify the
+   authorisation decisions listed at the start of this section, and that
+   the security of the chain of operations on which the APD entry
+   depends cannot be compromised.
+
+4.4.3.  Messaging Association Multiplexing
+
+   It is a design goal of GIST that, as far as possible, a single
+   messaging association should be used for multiple flows and sessions
+   between two peers, rather than setting up a new MA for each.  This
+   re-use of existing MAs is referred to as messaging association
+   multiplexing.  Multiplexing ensures that the MA cost scales only with
+   the number of peers, and avoids the latency of new MA setup where
+   possible.
+
+   However, multiplexing requires the identification of an existing MA
+   that matches the same routing state and desired properties that would
+   be the result of a normal handshake in D-mode, and this
+   identification must be done as reliably and securely as continuing
+   with a normal D-mode handshake.  Note that this requirement is
+   complicated by the fact that NATs may remap the node addresses in
+   D-mode messages, and also interacts with the fact that some nodes may
+   peer over multiple interfaces (and thus with different addresses).
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 39]
+
+RFC 5971                          GIST                      October 2010
+
+
+   MA multiplexing is controlled by the Network Layer Information (NLI)
+   object, which is carried in Query, Response, and Confirm messages.
+   The NLI object includes (among other elements):
+
+   Peer-Identity:  For a given node, this is an interface-independent
+      value with opaque syntax.  It MUST be chosen so as to have a high
+      probability of uniqueness across the set of all potential peers,
+      and SHOULD be stable at least until the next node restart.  Note
+      that there is no cryptographic protection of this identity;
+      attempting to provide this would essentially duplicate the
+      functionality in the messaging association security protocols.
+      For routers, the Router-ID [2], which is one of the router's IP
+      addresses, MAY be used as one possible value for the Peer-
+      Identity.  In scenarios with nested NATs, the Router-ID alone may
+      not satisfy the uniqueness requirements, in which case it MAY be
+      extended with additional tokens, either chosen randomly or
+      administratively coordinated.
+
+   Interface-Address:  This is an IP address through which the
+      signalling node can be reached.  There may be several choices
+      available for the Interface-Address, and further discussion of
+      this is contained in Section 5.2.2.
+
+   A messaging association is associated with the NLI object that was
+   provided by the peer in the Query/Response/Confirm at the time the
+   association was first set up.  There may be more than one MA for a
+   given NLI object, for example, with different security or transport
+   properties.
+
+   MA multiplexing is achieved by matching these two elements from the
+   NLI provided in a new GIST message with one associated with an
+   existing MA.  The message can be either a Query or Response, although
+   the former is more likely:
+
+   o  If there is a perfect match to an existing association, that
+      association SHOULD be re-used, provided it meets the criteria on
+      security and transport properties given at the end of
+      Section 5.7.1.  This is indicated by sending the remaining
+      messages in the handshake over that association.  This will lead
+      to multiplexing on an association to the wrong node if signalling
+      nodes have colliding Peer-Identities and one is reachable at the
+      same Interface-Address as another.  This could be caused by an on-
+      path attacker; on-path attacks are discussed further in
+      Section 8.7.  When multiplexing is done, and the original MA
+      authorisation was MRI-dependent, the verification steps of
+      Section 4.4.2 MUST be repeated for the new flow.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 40]
+
+RFC 5971                          GIST                      October 2010
+
+
+   o  In all other cases, the handshake MUST be executed in D-mode as
+      usual.  There are in fact four possibilities:
+
+      1.  Nothing matches: this is clearly a new peer.
+
+      2.  Only the Peer-Identity matches: this may be either a new
+          interface on an existing peer or a changed address mapping
+          behind a NAT.  These should be rare events, so the expense of
+          a new association setup is acceptable.  Another possibility is
+          one node using another node's Peer-Identity, for example, as
+          some kind of attack.  Because the Peer-Identity is used only
+          for this multiplexing process, the only consequence this has
+          is to require a new association setup, and this is considered
+          in Section 8.4.
+
+      3.  Only the Interface-Address matches: this is probably a new
+          peer behind the same NAT as an existing one.  A new
+          association setup is required.
+
+      4.  Both elements of the NLI object match: this is a degenerate
+          case, where one node recognises an existing peer, but wishes
+          to allow the option to set up a new association in any case,
+          for example, to create an association with different
+          properties.
+
+4.4.4.  Routing State Maintenance
+
+   Each item of routing state expires after a lifetime that is
+   negotiated during the Query/Response/Confirm handshake.  The Network
+   Layer Information (NLI) object in the Query contains a proposal for
+   the lifetime value, and the NLI in the Response contains the value
+   the Responding node requires.  A default timer value of 30 seconds is
+   RECOMMENDED.  Nodes that can exploit alternative, more powerful,
+   route change detection methods such as those described in
+   Section 7.1.2 MAY choose to use much longer times.  Nodes MAY use
+   shorter times to provide more rapid change detection.  If the number
+   of active routing state items corresponds to a rate of Queries that
+   will stress the rate limits applied to D-mode traffic
+   (Section 5.3.3), nodes MUST increase the timer for new items and on
+   the refresh of existing ones.  A suitable value is
+
+         2 * (number of routing states) / (rate limit in packets/second)
+
+   which leaves a factor of two headroom for new routing state creation
+   and Query retransmissions.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 41]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The Querying node MUST ensure that a Query is received before this
+   timer expires, if it believes that the signalling session is still
+   active; otherwise, the Responding node MAY delete the state.  Receipt
+   of the message at the Responding node will refresh peer addressing
+   state for one direction, and receipt of a Response at the Querying
+   node will refresh it for the other.  There is no mechanism at the
+   GIST level for explicit teardown of routing state.  However, GIST
+   MUST NOT refresh routing state if a signalling session is known to be
+   inactive, either because upstream state has expired or because the
+   signalling application has indicated via the GIST API (Appendix B.5)
+   that the state is no longer required, because this would prevent
+   correct state repair in the case of network rerouting at the IP
+   layer.
+
+   This specification defines precisely only the time at which routing
+   state expires; it does not define when refresh handshakes should be
+   initiated.  Implementations MUST select timer settings that take at
+   least the following into account:
+
+   o  the transmission latency between source and destination;
+
+   o  the need for retransmissions of Query messages;
+
+   o  the need to avoid network synchronisation of control traffic (cf.
+      [42]).
+
+   In most cases, a reasonable policy is to initiate the routing state
+   refresh when between 1/2 and 3/4 of the validity time has elapsed
+   since the last successful refresh.  The actual moment MUST be chosen
+   randomly within this interval to avoid synchronisation effects.
+
+4.4.5.  Messaging Association Maintenance
+
+   Unneeded MAs are torn down by GIST, using the teardown mechanisms of
+   the underlying transport or security protocols if available, for
+   example, by simply closing a TCP connection.  The teardown can be
+   initiated by either end.  Whether an MA is needed is a combination of
+   two factors:
+
+   o  local policy, which could take into account the cost of keeping
+      the messaging association open, the level of past activity on the
+      association, and the likelihood of future activity, e.g., if there
+      is routing state still in place that might generate messages to
+      use it.
+
+   o  whether the peer still wants the MA to remain in place.  During MA
+      setup, as part of the Stack-Configuration-Data, each node
+      advertises its own MA-Hold-Time, i.e., the time for which it will
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 42]
+
+RFC 5971                          GIST                      October 2010
+
+
+      retain an MA that is not carrying signalling traffic.  A node MUST
+      NOT tear down an MA if it has received traffic from its peer over
+      that period.  A peer that has generated no traffic but still wants
+      the MA retained can use a special null message (MA-Hello) to
+      indicate the fact.  A default value for MA-Hold-Time of 30 seconds
+      is RECOMMENDED.  Nodes MAY use shorter times to achieve more rapid
+      peer failure detection, but need to take into account the load on
+      the network created by the MA-Hello messages.  Nodes MAY use
+      longer times, but need to take into account the cost of retaining
+      idle MAs for extended periods.  Nodes MAY take signalling
+      application behaviour (e.g., NSLP refresh times) into account in
+      choosing an appropriate value.
+
+      Because the Responding node can choose not to create state until a
+      Confirm, an abbreviated Stack-Configuration-Data object containing
+      just this information from the initial Query MUST be repeated by
+      the Querying node in the first Confirm sent on a new MA.  If the
+      object is missing in the Confirm, an "Object Type Error" message
+      (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be
+      returned.
+
+   Messaging associations can always be set up on demand, and messaging
+   association status is not made directly visible outside the GIST
+   layer.  Therefore, even if GIST tears down and later re-establishes a
+   messaging association, signalling applications cannot distinguish
+   this from the case where the MA is kept permanently open.  To
+   maintain the transport semantics described in Section 4.1, GIST MUST
+   close transport connections carrying reliable messages gracefully or
+   report an error condition, and MUST NOT open a new association to be
+   used for given session and peer while messages on a previous
+   association could still be outstanding.  GIST MAY use an MA-Hello
+   request/reply exchange on an existing association to verify that
+   messages sent on it have reached the peer.  GIST MAY use the same
+   technique to test the liveness of the underlying MA protocols
+   themselves at arbitrary times.
+
+   This specification defines precisely only the time at which messaging
+   associations expire; it does not define when keepalives should be
+   initiated.  Implementations MUST select timer settings that take at
+   least the following into account:
+
+   o  the transmission latency between source and destination;
+
+   o  the need for retransmissions within the messaging association
+      protocols;
+
+   o  the need to avoid network synchronisation of control traffic (cf.
+      [42]).
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 43]
+
+RFC 5971                          GIST                      October 2010
+
+
+   In most cases, a reasonable policy is to initiate the MA refresh when
+   between 1/2 and 3/4 of the validity time has elapsed since the last
+   successful refresh.  The actual moment MUST be chosen randomly within
+   this interval to avoid synchronisation effects.
+
+4.4.6.  Routing State Failures
+
+   A GIST node can receive a message from a GIST peer that can only be
+   correctly processed in the context of some routing state, but where
+   no corresponding routing state exists.  Cases where this can arise
+   include:
+
+   o  Where the message is random traffic from an attacker, or
+      backscatter (replies to such traffic).
+
+   o  Where routing state has been correctly installed but the peer has
+      since lost it, for example, because of aggressive timeout settings
+      at the peer or because the node has crashed and restarted.
+
+   o  Where the routing state was not correctly installed in the first
+      place, but the sending node does not know this.  This can happen
+      if the Confirm message of the handshake is lost.
+
+   It is important for GIST to recover from such situations promptly
+   where they represent genuine errors (node restarts, or lost messages
+   that would not otherwise be retransmitted).  Note that only Response,
+   Confirm, Data, and Error messages ever require routing state to
+   exist, and these are considered in turn:
+
+   Response:  A Response can be received at a node that never sent (or
+      has forgotten) the corresponding Query.  If the node wants routing
+      state to exist, it will initiate it itself; a diagnostic error
+      would not allow the sender of the Response to take any corrective
+      action, and the diagnostic could itself be a form of backscatter.
+      Therefore, an error message MUST NOT be generated, but the
+      condition MAY be logged locally.
+
+   Confirm:  For a Responding node that implements delayed state
+      installation, this is normal behaviour, and routing state will be
+      created provided the Confirm is validated.  Otherwise, this is a
+      case of a non-existent or forgotten Response, and the node may not
+      have sufficient information in the Confirm to create the correct
+      state.  The requirement is to notify the Querying node so that it
+      can recover the routing state.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 44]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Data:  This arises when a node receives Data where routing state is
+      required, but either it does not exist at all or it has not been
+      finalised (no Confirm message).  To avoid Data being black-holed,
+      a notification must be sent to the peer.
+
+   Error:  Some error messages can only be interpreted in the context of
+      routing state.  However, the only error messages that require a
+      reply within the protocol are routing state error messages
+      themselves.  Therefore, this case should be treated the same as a
+      Response: an error message MUST NOT be generated, but the
+      condition MAY be logged locally.
+
+   For the case of Confirm or Data messages, if the state is required
+   but does not exist, the node MUST reject the incoming message with a
+   "No Routing State" error message (Appendix A.4.4.5).  There are then
+   three cases at the receiver of the error message:
+
+   No routing state:  The condition MAY be logged but a reply MUST NOT
+      be sent (see above).
+
+   Querying node:  The node MUST restart the GIST handshake from the
+      beginning, with a new Query.
+
+   Responding node:  The node MUST delete its own routing state and
+      SHOULD report an error condition to the local signalling
+      application.
+
+   The rules at the Querying or Responding node make GIST open to
+   disruption by randomly injected error messages, similar to blind
+   reset attacks on TCP (cf. [46]), although because routing state
+   matching includes the SID this is mainly limited to on-path
+   attackers.  If a GIST node detects a significant rate of such
+   attacks, it MAY adopt a policy of using secured messaging
+   associations to communicate for the affected MRIs, and only accepting
+   "No Routing State" error messages over such associations.
+
+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.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 45]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 46]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 47]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 48]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 49]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 50]
+
+RFC 5971                          GIST                      October 2010
+
+
+      *  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
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 51]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 52]
+
+RFC 5971                          GIST                      October 2010
+
+
+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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 53]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 54]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 55]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 56]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 57]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 58]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 59]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 60]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 61]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 62]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 63]
+
+RFC 5971                          GIST                      October 2010
+
+
+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
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 64]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 65]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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).
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 66]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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,
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 67]
+
+RFC 5971                          GIST                      October 2010
+
+
+      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.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 68]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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].
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 69]
+
+RFC 5971                          GIST                      October 2010
+
+
+   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.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 70]
+
+RFC 5971                          GIST                      October 2010
+
+
+6.  Formal Protocol Specification
+
+   This section provides a more formal specification of the operation of
+   GIST processing, in terms of rules for transitions between states of
+   a set of communicating state machines within a node.  The following
+   description captures only the basic protocol specification;
+   additional mechanisms can be used by an implementation to accelerate
+   route change processing, and these are captured in Section 7.1.  A
+   more detailed description of the GIST protocol operation in state
+   machine syntax can be found in [45].
+
+   Conceptually, GIST processing at a node may be seen in terms of four
+   types of cooperating state machine:
+
+   1.  There is a top-level state machine that represents the node
+       itself (Node-SM).  It is responsible for the processing of events
+       that cannot be directed towards a more specific state machine,
+       for example, inbound messages for which no routing state
+       currently exists.  This machine exists permanently, and is
+       responsible for creating per-MRI state machines to manage the
+       GIST handshake and routing state maintenance procedures.
+
+   2.  For each flow and signalling direction where the node is
+       responsible for the creation of routing state, there is an
+       instance of a Query-Node state machine (Querying-SM).  This
+       machine sends Query and Confirm messages and waits for Responses,
+       according to the requirements from local API commands or timer
+       processing, such as message repetition or routing state refresh.
+
+   3.  For each flow and signalling direction where the node has
+       accepted the creation of routing state by a peer, there is an
+       instance of a Responding-Node state machine (Responding-SM).
+       This machine is responsible for managing the status of the
+       routing state for that flow.  Depending on policy, it MAY be
+       responsible for transmission or retransmission of Response
+       messages, or this MAY be handled by the Node-SM, and a
+       Responding-SM is not even created for a flow until a properly
+       formatted Confirm has been accepted.
+
+   4.  Messaging associations have their own lifecycle, represented by
+       an MA-SM, from when they are first created (in an incomplete
+       state, listening for an inbound connection or waiting for
+       outbound connections to complete), to when they are active and
+       available for use.
+
+   Apart from the fact that the various machines can be created and
+   destroyed by each other, there is almost no interaction between them.
+   The machines for different flows do not interact; the Querying-SM and
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 71]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Responding-SM for a single flow and signalling direction do not
+   interact.  That is, the Responding-SM that accepts the creation of
+   routing state for a flow on one interface has no direct interaction
+   with the Querying-SM that sets up routing state on the next interface
+   along the path.  This interaction is mediated instead through the
+   NSLP.
+
+   The state machine descriptions use the terminology rx_MMMM, tg_TTTT,
+   and er_EEEE for incoming messages, API/lower layer triggers, and
+   error conditions, respectively.  The possible events of these types
+   are given in the table below.  In addition, timeout events denoted
+   to_TTTT may also occur; the various timers are listed independently
+   for each type of state machine in the following subsections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 72]
+
+RFC 5971                          GIST                      October 2010
+
+
+   +---------------------+---------------------------------------------+
+   | Name                | Meaning                                     |
+   +---------------------+---------------------------------------------+
+   | rx_Query            | A Query has been received.                  |
+   |                     |                                             |
+   | rx_Response         | A Response has been received.               |
+   |                     |                                             |
+   | rx_Confirm          | A Confirm has been received.                |
+   |                     |                                             |
+   | rx_Data             | A Data message has been received.           |
+   |                     |                                             |
+   | rx_Message          | rx_Query||rx_Response||rx_Confirm||rx_Data. |
+   |                     |                                             |
+   | rx_MA-Hello         | An MA-Hello message has been received.      |
+   |                     |                                             |
+   | tg_NSLPData         | A signalling application has requested data |
+   |                     | transfer (via API SendMessage).             |
+   |                     |                                             |
+   | tg_Connected        | The protocol stack for a messaging          |
+   |                     | association has completed connecting.       |
+   |                     |                                             |
+   | tg_RawData          | GIST wishes to transfer data over a         |
+   |                     | particular messaging association.           |
+   |                     |                                             |
+   | tg_MAIdle           | GIST decides that it is no longer necessary |
+   |                     | to keep an MA open for itself.              |
+   |                     |                                             |
+   | er_NoRSM            | A "No Routing State" error was received.    |
+   |                     |                                             |
+   | er_MAConnect        | A messaging association protocol failed to  |
+   |                     | complete a connection.                      |
+   |                     |                                             |
+   | er_MAFailure        | A messaging association failed.             |
+   +---------------------+---------------------------------------------+
+
+                              Incoming Events
+
+6.1.  Node Processing
+
+   The Node-level state machine is responsible for processing events for
+   which no more appropriate messaging association state or routing
+   state exists.  Its structure is trivial: there is a single state
+   ('Idle'); all events cause a transition back to Idle.  Some events
+   cause the creation of other state machines.  The only events that are
+   processed by this state machine are incoming GIST messages (Query/
+   Response/Confirm/Data) and API requests to send data; no other events
+   are possible.  In addition to this event processing, the Node-level
+   machine is responsible for managing listening endpoints for messaging
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 73]
+
+RFC 5971                          GIST                      October 2010
+
+
+   associations.  Although these relate to Responding node operation,
+   they cannot be handled by the Responder state machine since they are
+   not created per flow.  The processing rules for each event are as
+   follows:
+
+   Rule 1 (rx_Query):
+   use the GIST service interface to determine the signalling
+       application policy relating to this peer
+       // note that this interaction delivers any NSLP-Data to
+       // the NSLP as a side effect
+   if (the signalling application indicates that routing state should
+       be created) then
+     if (routing state can be created without a 3-way handshake) then
+       create Responding-SM and transfer control to it
+     else
+       send Response with R=1
+   else
+     propagate the Query with any updated NSLP payload provided
+
+   Rule 2 (rx_Response):
+   // a routing state error
+   discard message
+
+   Rule 3 (rx_Confirm):
+   if (routing state can be created before receiving a Confirm) then
+     // we should already have Responding-SM for it,
+     // which would handle this message
+     discard message
+     send "No Routing State" error message
+   else
+     create Responding-SM and pass message to it
+
+   Rule 4 (rx_Data):
+   if (node policy will only process Data messages with matching
+       routing state) then
+     send "No Routing State" error message
+   else
+     pass directly to NSLP
+
+   Rule 4 (er_NoRSM):
+   discard the message
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 74]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Rule 5 (tg_NSLPData):
+   if Q-mode encapsulation is not possible for this MRI
+     reject message with an error
+   else
+     if (local policy & transfer attributes say routing
+         state is not needed) then
+       send message statelessly
+     else
+       create Querying-SM and pass message to it
+
+6.2.  Query Node Processing
+
+   The Querying-Node state machine (Querying-SM) has three states:
+
+   o  Awaiting Response
+
+   o  Established
+
+   o  Awaiting Refresh
+
+   The Querying-SM is created by the Node-SM machine as a result of a
+   request to send a message for a flow in a signalling direction where
+   the appropriate state does not exist.  The Query is generated
+   immediately and the No_Response timer is started.  The NSLP data MAY
+   be carried in the Query if local policy and the transfer attributes
+   allow it; otherwise, it MUST be queued locally pending MA
+   establishment.  Then the machine transitions to the Awaiting Response
+   state, in which timeout-based retransmissions are handled.  Data
+   messages (rx_Data events) should not occur in this state; if they do,
+   this may indicate a lost Response and a node MAY retransmit a Query
+   for this reason.
+
+   Once a Response has been successfully received and routing state
+   created, the machine transitions to Established, during which NSLP
+   data can be sent and received normally.  Further Responses received
+   in this state (which may be the result of a lost Confirm) MUST be
+   treated the same way.  The Awaiting Refresh state can be considered
+   as a substate of Established, where a new Query has been generated to
+   refresh the routing state (as in Awaiting Response) but NSLP data can
+   be handled normally.
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 75]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The timers relevant to this state machine are as follows:
+
+   Refresh_QNode:  Indicates when the routing state stored by this state
+      machine must be refreshed.  It is reset whenever a Response is
+      received indicating that the routing state is still valid.
+      Implementations MUST set the period of this timer based on the
+      value in the RS-validity-time field of a Response to ensure that a
+      Query is generated before the peer's routing state expires (see
+      Section 4.4.4).
+
+   No_Response:  Indicates that a Response has not been received in
+      answer to a Query.  This is started whenever a Query is sent and
+      stopped when a Response is received.
+
+   Inactive_QNode:  Indicates that no NSLP traffic is currently being
+      handled by this state machine.  This is reset whenever the state
+      machine handles NSLP data, in either direction.  When it expires,
+      the state machine MAY be deleted.  The period of the timer can be
+      set at any time via the API (SetStateLifetime), and if the period
+      is reset in this way the timer itself MUST be restarted.
+
+   The main events (including all those that cause state transitions)
+   are shown in the figure below, tagged with the number of the
+   processing rule that is used to handle the event.  These rules are
+   listed after the diagram.  All events not shown or described in the
+   text above are assumed to be impossible in a correct implementation
+   and MUST be ignored.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 76]
+
+RFC 5971                          GIST                      October 2010
+
+
+              [Initialisation]   +-----+
+        -------------------------|Birth|
+       |                         +-----+
+       | er_NoRSM[3](from all states)                   rx_Response[4]
+       |                                               || tg_NSLPData[5]
+       |      tg_NSLPData[1]                           || rx_Data[7]
+       |        --------                                    -------
+       |       |        V                                  |       V
+       |       |        V                                  |       V
+       |      +----------+                               +-----------+
+        ---->>| Awaiting |                               |Established|
+        ------| Response |---------------------------->> |           |
+       |      +----------+       rx_Response[4]          +-----------+
+       |       ^        |                                     ^   |
+       |       ^        |                                     ^   |
+       |        --------                                      |   |
+       |    to_No_Response[2]                                 |   |
+       |    [!nResp_reached]     tg_NSLPData[5]               |   |
+       |                         || rx_Data[7]                |   |
+       |                          --------                    |   |
+       |                         |        V                   |   |
+       |    to_No_Response[2]    |        V                   |   |
+       |     [nResp_reached]    +-----------+  rx_Response[4] |   |
+        ----------   -----------|  Awaiting |-----------------    |
+                  | |           |  Refresh  |<<-------------------
+                  | |           +-----------+    to_Refresh_QNode[8]
+                  | |            ^        |
+                  V V            ^        | to_No_Response[2]
+                  V V             --------  [!nResp_reached]
+                +-----+
+                |Death|<<---------------
+                +-----+   to_Inactive_QNode[6]
+                          (from all states)
+
+                    Figure 7: Query Node State Machine
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 77]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The processing rules are as follows:
+
+   Rule 1:
+      Store the message for later transmission
+
+   Rule 2:
+   if number of Queries sent has reached the threshold
+     // nQuery_isMax is true
+     indicate No Response error to NSLP
+     destroy self
+   else
+     send Query
+     start No_Response timer with new value
+
+   Rule 3:
+   // Assume the Confirm was lost in transit or the peer has reset;
+   // restart the handshake
+   send Query
+   (re)start No_Response timer
+
+   Rule 4:
+   if a new MA-SM is needed create one
+   if the R-flag was set send a Confirm
+   send any stored Data messages
+   stop No_Response timer
+   start Refresh_QNode timer
+   start Inactive_QNode timer if it was not running
+   if there was piggybacked NSLP-Data
+     pass it to the NSLP
+     restart Inactive_QNode timer
+
+   Rule 5:
+   send Data message
+   restart Inactive_QNode timer
+
+   Rule 6:
+      Terminate
+
+   Rule 7:
+   pass any data to the NSLP
+   restart Inactive_QNode timer
+
+   Rule 8:
+   send Query
+   start No_Response timer
+   stop Refresh_QNode timer
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 78]
+
+RFC 5971                          GIST                      October 2010
+
+
+6.3.  Responder Node Processing
+
+   The Responding-Node state machine (Responding-SM) has three states:
+
+   o  Awaiting Confirm
+
+   o  Established
+
+   o  Awaiting Refresh
+
+   The policy governing the handling of Query messages and the creation
+   of the Responding-SM has three cases:
+
+   1.  No Confirm is required for a Query, and the state machine can be
+       created immediately.
+
+   2.  A Confirm is required for a Query, but the state machine can
+       still be created immediately.  A timer is used to retransmit
+       Response messages and the Responding-SM is destroyed if no valid
+       Confirm is received.
+
+   3.  A Confirm is required for a Query, and the state machine can only
+       be created when it is received; the initial Query will have been
+       handled by the Node-level machine.
+
+   In case 2, the Responding-SM is created in the Awaiting Confirm
+   state, and remains there until a Confirm is received, at which point
+   it transitions to Established.  In cases 1 and 3, the Responding-SM
+   is created directly in the Established state.  Note that if the
+   machine is created on receiving a Query, some of the message
+   processing will already have been performed in the node state
+   machine.  In principle, an implementation MAY change its policy on
+   handling a Query message at any time; however, the state machine
+   descriptions here cover only the case where the policy is fixed while
+   waiting for a Confirm message.
+
+   In the Established state, the NSLP can send and receive data
+   normally, and any additional rx_Confirm events MUST be silently
+   ignored.  The Awaiting Refresh state can be considered a substate of
+   Established, where a Query has been received to begin the routing
+   state refresh.  In the Awaiting Refresh state, the Responding-SM
+   behaves as in the Awaiting Confirm state, except that the NSLP can
+   still send and receive data.  In particular, in both states there is
+   timer-based retransmission of Response messages until a Confirm is
+   received; additional rx_Query events in these states MUST also
+   generate a reply and restart the no_Confirm timer.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 79]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The timers relevant to the operation of this state machine are as
+   follows:
+
+   Expire_RNode:  Indicates when the routing state stored by this state
+      machine needs to be expired.  It is reset whenever a Query or
+      Confirm (depending on local policy) is received indicating that
+      the routing state is still valid.  Note that state cannot be
+      refreshed from the R-Node.  If this timer fires, the routing state
+      machine is deleted, regardless of whether a No_Confirm timer is
+      running.
+
+   No_Confirm:  Indicates that a Confirm has not been received in answer
+      to a Response.  This is started/reset whenever a Response is sent
+      and stopped when a Confirm is received.
+
+   The detailed state transitions and processing rules are described
+   below as in the Query node case.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 80]
+
+RFC 5971                          GIST                      October 2010
+
+
+               rx_Query[1]                      rx_Query[5]
+            [confirmRequired]    +-----+    [!confirmRequired]
+        -------------------------|Birth|----------------------------
+       |                         +-----+                            |
+       |                            |         rx_Confirm[2]         |
+       |                             ----------------------------   |
+       |                                                         |  |
+       |                                       rx_Query[5]       |  |
+       |     tg_NSLPData[7]                   || rx_Confirm[10]  |  |
+       |      || rx_Query[1]                  || rx_Data[4]      |  |
+       |      || rx_Data[6]                   || tg_NSLPData[3]  |  |
+       |        --------                        --------------   |  |
+       |       |        V                      |              V  V  V
+       |       |        V                      |              V  V  V
+       |      +----------+                     |           +-----------+
+        ---->>| Awaiting |     rx_Confirm[8]    -----------|Established|
+        ------| Confirm  |------------------------------>> |           |
+       |      +----------+                                 +-----------+
+       |       ^        |                                      ^   |
+       |       ^        |         tg_NSLPData[3]               ^   |
+       |        --------          || rx_Query[1]               |   |
+       |    to_No_Confirm[9]      || rx_Data[4]                |   |
+       |    [!nConf_reached]       --------                    |   |
+       |                          |        V                   |   |
+       |    to_No_Confirm[9]      |        V                   |   |
+       |    [nConf_reached]      +-----------+  rx_Confirm[8]  |   |
+        ----------   ------------|  Awaiting |-----------------    |
+                  | |            |  Refresh  |<<-------------------
+                  | |            +-----------+      rx_Query[1]
+                  | |             ^        |     [confirmRequired]
+                  | |             ^        |
+                  | |              --------
+                  V V          to_No_Confirm[9]
+                  V V          [!nConf_reached]
+                +-----+
+                |Death|<<---------------------
+                +-----+    er_NoRSM[11]
+                           to_Expire_RNode[11]
+                               (from Established/Awaiting Refresh)
+
+                  Figure 8: Responder Node State Machine
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 81]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The processing rules are as follows:
+
+   Rule 1:
+   // a Confirm is required
+   send Response with R=1
+   (re)start No_Confirm timer with the initial timer value
+
+   Rule 2:
+   pass any NSLP-Data object to the NSLP
+   start Expire_RNode timer
+
+   Rule 3:  send the Data message
+
+   Rule 4:  pass data to NSLP
+
+   Rule 5:
+   // no Confirm is required
+   send Response with R=0
+   start Expire_RNode timer
+
+   Rule 6:
+   drop incoming data
+   send "No Routing State" error message
+
+   Rule 7:  store Data message
+
+   Rule 8:
+   pass any NSLP-Data object to the NSLP
+   send any stored Data messages
+   stop No_Confirm timer
+   start Expire_RNode timer
+
+   Rule 9:
+   if number of Responses sent has reached threshold
+     // nResp_isMax is true
+     destroy self
+   else
+     send Response
+     start No_Response timer
+
+   Rule 10:
+ // can happen e.g., a retransmitted Response causes a duplicate Confirm
+ silently ignore
+
+   Rule 11:  destroy self
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 82]
+
+RFC 5971                          GIST                      October 2010
+
+
+6.4.  Messaging Association Processing
+
+   Messaging associations (MAs) are modelled for use within GIST with a
+   simple three-state process.  The Awaiting Connection state indicates
+   that the MA is waiting for the connection process(es) for every
+   protocol in the messaging association to complete; this might involve
+   creating listening endpoints or attempting active connects.  Timers
+   may also be necessary to detect connection failure (e.g., no incoming
+   connection within a certain period), but these are not modelled
+   explicitly.
+
+   The Connected state indicates that the MA is open and ready to use
+   and that the node wishes it to remain open.  In this state, the node
+   operates a timer (SendHello) to ensure that messages are regularly
+   sent to the peer, to ensure that the peer does not tear down the MA.
+   The node transitions from Connected to Idle (indicating that it no
+   longer needs the association) as a matter of local policy; one way to
+   manage the policy is to use an activity timer but this is not
+   specified explicitly by the state machine (see also Section 4.4.5).
+
+   In the Idle state, the node no longer requires the messaging
+   association but the peer still requires it and is indicating this by
+   sending periodic MA-Hello messages.  A different timer (NoHello)
+   operates to purge the MA when these messages stop arriving.  If real
+   data is transferred over the MA, the state machine transitions back
+   to Connected.
+
+   At any time in the Connected or Idle states, a node MAY test the
+   connectivity to its peer and the liveness of the GIST instance at
+   that peer by sending an MA-Hello request with R=1.  Failure to
+   receive a reply with a matching Hello-ID within a timeout MAY be
+   taken as a reason to trigger er_MAFailure.  Initiation of such a test
+   and the timeout setting are left to the discretion of the
+   implementation.  Note that er_MAFailure may also be signalled by
+   indications from the underlying messaging association protocols.  If
+   a messaging association fails, this MUST be indicated back to the
+   routing state machines that use it, and these MAY generate
+   indications to signalling applications.  In particular, if the
+   messaging association was being used to deliver messages reliably,
+   this MUST be reported as a NetworkNotification error (Appendix B.4).
+
+   Clearly, many internal details of the messaging association protocols
+   are hidden in this model, especially where the messaging association
+   uses multiple protocol layers.  Note also that although the existence
+   of messaging associations is not directly visible to signalling
+   applications, there is some interaction between the two because
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 83]
+
+RFC 5971                          GIST                      October 2010
+
+
+   security-related information becomes available during the open
+   process, and this may be indicated to signalling applications if they
+   have requested it.
+
+   The timers relevant to the operation of this state machine are as
+   follows:
+
+   SendHello:  Indicates that an MA-Hello message should be sent to the
+      remote node.  The period of this timer is determined by the MA-
+      Hold-Time sent by the remote node during the Query/Response/
+      Confirm exchange.
+
+   NoHello:  Indicates that no MA-Hello has been received from the
+      remote node for a period of time.  The period of this timer is
+      sent to the remote node as the MA-Hold-Time during the Query/
+      Response exchange.
+
+   The detailed state transitions and processing rules are described
+   below as in the Query node case.
+
+            [Initialisation]       +-----+
+       ----------------------------|Birth|
+      |                            +-----+       tg_RawData[1]
+      |                                          || rx_Message[2]
+      |                                          || rx_MA-Hello[3]
+      |       tg_RawData[5]                      || to_SendHello[4]
+      |        --------                             --------
+      |       |        V                           |        V
+      |       |        V                           |        V
+      |      +----------+                         +-----------+
+       ---->>| Awaiting |    tg_Connected[6]      | Connected |
+       ------|Connection|----------------------->>|           |
+      |      +----------+                         +-----------+
+      |                                              ^    |
+      |                              tg_RawData[1]   ^    |
+      |                            || rx_Message[2]  |    | tg_MAIdle[7]
+      |                                              |    V
+      |                                              |    V
+      | er_MAConnect[8]  +-----+   to_NoHello[8]  +-----------+
+       ---------------->>|Death|<<----------------|   Idle    |
+                         +-----+                  +-----------+
+                           ^                       ^        |
+                           ^                       ^        |
+                            ---------------         --------
+                            er_MAFailure[8]        rx_MA-Hello[9]
+                         (from Connected/Idle)
+
+               Figure 9: Messaging Association State Machine
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 84]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The processing rules are as follows:
+
+   Rule 1:
+   pass message to transport layer
+   if the NoHello timer was running, stop it
+   (re)start SendHello
+
+   Rule 2:
+   pass message to Node-SM, or R-SM (for a Confirm),
+      or Q-SM (for a Response)
+   if the NoHello timer was running, stop it
+
+   Rule 3:
+   if reply requested
+     send MA-Hello
+     restart SendHello timer
+
+   Rule 4:
+   send MA-Hello message
+   restart SendHello timer
+
+   Rule 5:
+      queue message for later transmission
+
+   Rule 6:
+   pass outstanding queued messages to transport layer
+   stop any timers controlling connection establishment
+   start SendHello timer
+
+   Rule 7:
+   stop SendHello timer
+   start NoHello timer
+
+   Rule 8:
+   report failure to routing state machines and signalling applications
+   destroy self
+
+   Rule 9:
+   if reply requested
+     send MA-Hello
+   restart NoHello timer
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 85]
+
+RFC 5971                          GIST                      October 2010
+
+
+7.  Additional Protocol Features
+
+7.1.  Route Changes and Local Repair
+
+7.1.1.  Introduction
+
+   When IP layer rerouting takes place in the network, GIST and
+   signalling application state need to be updated for all flows whose
+   paths have changed.  The updates to signalling application state
+   depend mainly on the signalling application: for example, if the path
+   characteristics have changed, simply moving state from the old to the
+   new path is not sufficient.  Therefore, GIST cannot complete the path
+   update processing by itself.  Its responsibilities are to detect the
+   route change, update its local routing state consistently, and inform
+   interested signalling applications at affected nodes.
+
+                        xxxxxxxxxxxxxxxxxxxxxxxxxxxx
+                       x  +--+      +--+      +--+  x      Initial
+                      x  .|C1|_.....|D1|_.....|E1|   x     Configuration
+                     x  . +--+.    .+--+.    .+--+\.  x
+      >>xxxxxxxxxxxxx  .       .  .      .  .       .  xxxxxx>>
+        +-+       +-+ .         ..        ..         . +-+
+     ...|A|_......|B|/          ..        ..          .|F|_....
+        +-+       +-+ .        .  .      .  .        . +-+
+                       .      .    .    .    .      .
+                        . +--+      +--+      +--+ .
+                         .|C2|_.....|D2|_.....|E2|/
+                          +--+      +--+      +--+
+
+                          +--+      +--+      +--+         Configuration
+                         .|C1|......|D1|......|E1|         after failure
+                        . +--+     .+--+      +--+         of E1-F link
+                       .      \.  .     \.  ./
+        +-+       +-+ .         ..        ..           +-+
+     ...|A|_......|B|.          ..        ..          .|F|_....
+        +-+       +-+\         .  .      .  .        . +-+
+      >>xxxxxxxxxxxxx .       .    .    .    .      .  xxxxxx>>
+                     x  . +--+      +--+      +--+ .  x
+                      x  .|C2|_.....|D2|_.....|E2|/  x
+                       x  +--+      +--+      +--+  x
+                        xxxxxxxxxxxxxxxxxxxxxxxxxxxx
+
+               ........... = physical link topology
+               >>xxxxxxx>> = flow direction
+               _.......... = outgoing link for flow xxxxxx given
+                             by local forwarding table
+
+                       Figure 10: A Rerouting Event
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 86]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Route change management is complicated by the distributed nature of
+   the problem.  Consider the rerouting event shown in Figure 10.  An
+   external observer can tell that the main responsibility for
+   controlling the updates will probably lie with nodes B and F;
+   however, E1 is best placed to detect the event quickly at the GIST
+   level, and C1 and D1 could also attempt to initiate the repair.
+
+   The NSIS framework [29] makes the assumption that signalling
+   applications are soft-state based and operate end to end.  In this
+   case, because GIST also periodically updates its picture of routing
+   state, route changes will eventually be repaired automatically.  The
+   specification as already given includes this functionality.  However,
+   especially if upper layer refresh times are extended to reduce
+   signalling load, the duration of inconsistent state may be very long
+   indeed.  Therefore, GIST includes logic to exchange prompt
+   notifications with signalling applications, to allow local repair if
+   possible.  The additional mechanisms to achieve this are described in
+   the following subsections.  To a large extent, these additions can be
+   seen as implementation issues; the protocol messages and their
+   significance are not changed, but there are extra interactions
+   through the API between GIST and signalling applications, and
+   additional triggers for transitions between the various GIST states.
+
+7.1.2.  Route Change Detection Mechanisms
+
+   There are two aspects to detecting a route change at a single node:
+
+   o  Detecting that the outgoing path, in the direction of the Query,
+      has or may have changed.
+
+   o  Detecting that the incoming path, in the direction of the
+      Response, has (or may have) changed, in which case the node may no
+      longer be on the path at all.
+
+   At a single node, these processes are largely independent, although
+   clearly a change in one direction at a node corresponds to a change
+   in the opposite direction at its peer.  Note that there are two
+   possible forms for a route change: the interface through which a flow
+   leaves or enters a node may change, and the adjacent peer may change.
+   In general, a route change can include one or the other or both (or
+   indeed neither, although such changes are very hard to detect).
+
+   The route change detection mechanisms available to a node depend on
+   the MRM in use and the role the node played in setting up the routing
+   state in the first place (i.e., as Querying or Responding node).  The
+   following discussion is specific to the case of the path-coupled MRM
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 87]
+
+RFC 5971                          GIST                      October 2010
+
+
+   using downstream Queries only; other scenarios may require other
+   methods.  However, the repair logic described in the subsequent
+   subsections is intended to be universal.
+
+   There are five mechanisms for a node to detect that a route change
+   has occurred, which are listed below.  They apply differently
+   depending on whether the change is in the Query or Response
+   direction, and these differences are summarised in the following
+   table.
+
+   Local Trigger:  In local trigger mode, GIST finds out from the local
+      forwarding table that the next hop has changed.  This only works
+      if the routing change is local, not if it happens a few IP routing
+      hops away, including the case that it happens at a GIST-unaware
+      node.
+
+   Extended Trigger:  Here, GIST checks a link-state topology database
+      to discover that the path has changed.  This makes certain
+      assumptions on consistency of IP route computation and only works
+      within a single area for OSPF [16] and similar link-state
+      protocols.  Where available, this offers the most accurate and
+      rapid indication of route changes, but requires more access to the
+      routing internals than a typical operating system may provide.
+
+   GIST C-mode Monitoring:  GIST may find that C-mode packets are
+      arriving (from either peer) with a different IP layer TTL or on a
+      different interface.  This provides no direct information about
+      the new flow path, but indicates that routing has changed and that
+      rediscovery may be required.
+
+   Data Plane Monitoring:  The signalling application on a node may
+      detect a change in behaviour of the flow, such as IP layer TTL
+      change, arrival on a different interface, or loss of the flow
+      altogether.  The signalling application on the node is allowed to
+      convey this information to the local GIST instance (Appendix B.6).
+
+   GIST Probing:  According to the specification, each GIST node MUST
+      periodically repeat the discovery (Query/Response) operation.
+      Values for the probe frequency are discussed in Section 4.4.4.
+      The period can be negotiated independently for each GIST hop, so
+      nodes that have access to the other techniques listed above MAY
+      use long periods between probes.  The Querying node will discover
+      the route change by a modification in the Network-Layer-
+      Information in the Response.  The Responding node can detect a
+      change in the upstream peer similarly; further, if the Responding
+      node can store the interface on which Queries arrive, it can
+      detect if this interface changes even when the peer does not.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 88]
+
+RFC 5971                          GIST                      October 2010
+
+
+   +-------------+--------------------------+--------------------------+
+   | Method      | Query direction          | Response direction       |
+   +-------------+--------------------------+--------------------------+
+   | Local       | Discovers new interface  | Not applicable           |
+   | Trigger     | (and peer if local)      |                          |
+   |             |                          |                          |
+   | Extended    | Discovers new interface  | May determine that route |
+   | Trigger     | and may determine new    | from peer will have      |
+   |             | peer                     | changed                  |
+   |             |                          |                          |
+   | C-mode      | Provides hint that       | Provides hint that       |
+   | Monitoring  | change has occurred      | change has occurred      |
+   |             |                          |                          |
+   | Data Plane  | Not applicable           | NSLP informs GIST that a |
+   | Monitoring  |                          | change may have occurred |
+   |             |                          |                          |
+   | Probing     | Discovers changed NLI in | Discovers changed NLI in |
+   |             | Response                 | Query                    |
+   +-------------+--------------------------+--------------------------+
+
+7.1.3.  GIST Behaviour Supporting Rerouting
+
+   The basic GIST behaviour necessary to support rerouting can be
+   modelled using a three-level classification of the validity of each
+   item of current routing state.  (In addition to current routing
+   state, NSIS can maintain past routing state, described in
+   Section 7.1.4 below.)  This classification applies separately to the
+   Querying and Responding nodes for each pair of GIST peers.  The
+   levels are:
+
+   Bad:  The routing state is either missing altogether or not safe to
+      use to send data.
+
+   Tentative:  The routing state may have changed, but it is still
+      usable for sending NSLP data pending verification.
+
+   Good:  The routing state has been established and no events affecting
+      it have since been detected.
+
+   These classifications are not identical to the states described in
+   Section 6, but there are dependencies between them.  Specifically,
+   routing state is considered Bad until the state machine first enters
+   the Established state, at which point it becomes Good.  Thereafter,
+   the status may be invalidated for any of the reasons discussed above;
+   it is an implementation issue to decide which techniques to implement
+   in any given node, and how to reclassify routing state (as Bad or
+   Tentative) for each.  The status returns to Good, either when the
+   state machine re-enters the Established state or if GIST can
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 89]
+
+RFC 5971                          GIST                      October 2010
+
+
+   determine from direct examination of the IP routing or forwarding
+   tables that the peer has not changed.  When the status returns to
+   Good, GIST MUST if necessary update its routing state table so that
+   the relationships between MRI/SID/NSLPID tuples and messaging
+   associations are up to date.
+
+   When classification of the routing state for the downstream direction
+   changes to Bad/Tentative because of local IP routing indications,
+   GIST MAY automatically change the classification in the upstream
+   direction to Tentative unless local routing indicates that this is
+   not necessary.  This SHOULD NOT be done in the case where the initial
+   change was indicated by the signalling application.  This mechanism
+   accounts for the fact that a routing change may affect several nodes,
+   and so can be an indication that upstream routing may also have
+   changed.  In any case, whenever GIST updates the routing status, it
+   informs the signalling application with the NetworkNotification API
+   (Appendix B.4), unless the change was caused via the API in the first
+   place.
+
+   The GIST behaviour for state repair is different for the Querying and
+   Responding nodes.  At the Responding node, there is no additional
+   behaviour, since the Responding node cannot initiate protocol
+   transitions autonomously.  (It can only react to the Querying node.)
+   The Querying node has three options, depending on how the transition
+   from Good was initially caused:
+
+   1.  To inspect the IP routing/forwarding table and verifying that the
+       next peer has not changed.  This technique MUST NOT be used if
+       the transition was caused by a signalling application, but SHOULD
+       be used otherwise if available.
+
+   2.  To move to the Awaiting Refresh state.  This technique MUST NOT
+       be used if the current status is Bad, since data is being
+       incorrectly delivered.
+
+   3.  To move to the Awaiting Response state.  This technique may be
+       used at any time, but has the effect of freezing NSLP
+       communication while GIST state is being repaired.
+
+   The second and third techniques trigger the execution of a GIST
+   handshake to carry out the repair.  It may be desirable to delay the
+   start of the handshake process, either to wait for the network to
+   stabilise, to avoid flooding the network with Query traffic for a
+   large number of affected flows, or to wait for confirmation that the
+   node is still on the path from the upstream peer.  One approach is to
+   delay the handshake until there is NSLP data to be transmitted.
+   Implementation of such delays is a matter of local policy; however,
+   GIST MUST begin the handshake immediately if the status change was
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 90]
+
+RFC 5971                          GIST                      October 2010
+
+
+   caused by an InvalidateRoutingState API call marked as 'Urgent', and
+   SHOULD begin it if the upstream routing state is still known to be
+   Good.
+
+7.1.4.  Load Splitting and Route Flapping
+
+   The Q-mode encapsulation rules of Section 5.8 try to ensure that the
+   Query messages discovering the path mimic the flow as accurately as
+   possible.  However, in environments where there is load balancing
+   over multiple routes, and this is based on header fields differing
+   between flow and Q-mode packets or done on a round-robin basis, the
+   path discovered by the Query may vary from one handshake to the next
+   even though the underlying network is stable.  This will appear to
+   GIST as a route flap; route flapping can also be caused by problems
+   in the basic network connectivity or routing protocol operation.  For
+   example, a mobile node might be switching back and forth between two
+   links, or might appear to have disappeared even though it is still
+   attached to the network via a different route.
+
+   This specification does not define mechanisms for GIST to manage
+   multiple parallel routes or an unstable route; instead, GIST MAY
+   expose this to the NSLP, which can then manage it according to
+   signalling application requirements.  The algorithms already
+   described always maintain the concept of the current route, i.e., the
+   latest peer discovered for a particular flow.  Instead, GIST allows
+   the use of prior signalling paths for some period while the
+   signalling applications still need them.  Since NSLP peers are a
+   single GIST hop apart, the necessary information to represent a path
+   can be just an entry in the node's routing state table for that flow
+   (more generally, anything that uniquely identifies the peer, such as
+   the NLI, could be used).  Rather than requiring GIST to maintain
+   multiple generations of this information, it is provided to the
+   signalling application in the same node in an opaque form for each
+   message that is received from the peer.  The signalling application
+   can store it if necessary and provide it back to the GIST layer in
+   case it needs to be used.  Because this is a reference to information
+   about the source of a prior signalling message, it is denoted 'SII-
+   Handle' (for Source Identification Information) in the abstract API
+   of Appendix B.
+
+   Note that GIST if possible SHOULD use the same SII-Handle for
+   multiple sessions to the same peer, since this then allows signalling
+   applications to aggregate some signalling, such as summary refreshes
+   or bulk teardowns.  Messages sent using the SII-Handle MUST bypass
+   the routing state tables at the sender, and this MUST be indicated by
+   setting the E-flag in the common header (Appendix A.1).  Messages
+   other than Data messages MUST NOT be sent in this way.  At the
+   receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 91]
+
+RFC 5971                          GIST                      October 2010
+
+
+   routing state and instead indicates the mode of reception to
+   signalling applications through the API (Appendix B.2).  Signalling
+   applications should validate the source and effect of the message
+   themselves, and if appropriate should in particular indicate to GIST
+   (see Appendix B.5) that routing state is no longer required for this
+   flow.  This is necessary to prevent GIST in nodes on the old path
+   initiating routing state refresh and thus causing state conflicts at
+   the crossover router.
+
+   GIST notifies signalling applications about route modifications as
+   two types of event, additions and deletions.  An addition is notified
+   as a change of the current routing state according to the Bad/
+   Tentative/Good classification above, while deletion is expressed as a
+   statement that an SII-Handle no longer lies on the path.  Both can be
+   reported through the NetworkNotification API call (Appendix B.4).  A
+   minimal implementation MAY notify a route change as a single (add,
+   delete) operation; however, a more sophisticated implementation MAY
+   delay the delete notification, for example, if it knows that the old
+   route continues to be used in parallel or that the true route is
+   flapping between the two.  It is then a matter of signalling
+   application design whether to tear down state on the old path, leave
+   it unchanged, or modify it in some signalling application specific
+   way to reflect the fact that multiple paths are operating in
+   parallel.
+
+7.1.5.  Signalling Application Operation
+
+   Signalling applications can use these functions as provided by GIST
+   to carry out rapid local repair following rerouting events.  The
+   signalling application instances carry out the multi-hop aspects of
+   the procedure, including crossover node detection, and tear-down/
+   reinstallation of signalling application state; they also trigger
+   GIST to carry out the local routing state maintenance operations over
+   each individual hop.  The local repair procedures depend heavily on
+   the fact that stateful NSLP nodes are a single GIST hop apart; this
+   is enforced by the details of the GIST peer discovery process.
+
+   The following outline description of a possible set of NSLP actions
+   takes the scenario of Figure 10 as an example.
+
+   1.  The signalling application at node E1 is notified by GIST of
+       route changes affecting the downstream and upstream directions.
+       The downstream status was updated to Bad because of a trigger
+       from the local forwarding tables, and the upstream status changed
+       automatically to Tentative as a consequence.  The signalling
+       application at E1 MAY begin local repair immediately, or MAY
+       propagate a notification upstream to D1 that rerouting has
+       occurred.
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 92]
+
+RFC 5971                          GIST                      October 2010
+
+
+   2.  The signalling application at node D1 is notified of the route
+       change, either by signalling application notifications or from
+       the GIST level (e.g., by a trigger from a link-state topology
+       database).  If the information propagates faster within the IP
+       routing protocol, GIST will change the upstream/downstream
+       routing state to Tentative/Bad automatically, and this will cause
+       the signalling application to propagate the notification further
+       upstream.
+
+   3.  This process continues until the notification reaches node A.
+       Here, there is no downstream routing change, so GIST only learns
+       of the update via the signalling application trigger.  Since the
+       upstream status is still Good, it therefore begins the repair
+       handshake immediately.
+
+   4.  The handshake initiated by node A causes its downstream routing
+       state to be confirmed as Good and unchanged there; it also
+       confirms the (Tentative) upstream routing state at B as Good.
+       This is enough to identify B as the crossover router, and the
+       signalling application and GIST can begin the local repair
+       process.
+
+   An alternative way to reach step (4) is that node B is able to
+   determine autonomously that there is no likelihood of an upstream
+   route change.  For example, it could be an area border router and the
+   route change is only intra-area.  In this case, the signalling
+   application and GIST will see that the upstream state is Good and can
+   begin the local repair directly.
+
+   After a route deletion, a signalling application may wish to remove
+   state at another node that is no longer on the path.  However, since
+   it is no longer on the path, in principle GIST can no longer send
+   messages to it.  In general, provided this state is soft, it will
+   time out anyway; however, the timeouts involved may have been set to
+   be very long to reduce signalling load.  Instead, signalling
+   applications MAY use the SII-Handle described above to route explicit
+   teardown messages.
+
+7.2.  NAT Traversal
+
+   GIST messages, for example, for the path-coupled MRM, must carry
+   addressing and higher layer information as payload data in order to
+   define the flow signalled for.  (This applies to all GIST messages,
+   regardless of how they are encapsulated or which direction they are
+   travelling in.)  At an addressing boundary, the data flow packets
+   will have their headers translated; if the signalling payloads are
+   not translated consistently, the signalling messages will refer to
+   incorrect (and probably meaningless) flows after passing through the
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 93]
+
+RFC 5971                          GIST                      October 2010
+
+
+   boundary.  In addition, GIST handshake messages carry additional
+   addressing information about the GIST nodes themselves, and this must
+   also be processed appropriately when traversing a NAT.
+
+   There is a dual problem of whether the GIST peers on either side of
+   the boundary can work out how to address each other, and whether they
+   can work out what translation to apply to the signalling packet
+   payloads.  Existing generic NAT traversal techniques such as Session
+   Traversal Utilities for NAT (STUN) [26] or Traversal Using Relays
+   around NAT (TURN) [27] can operate only on the two addresses visible
+   in the IP header.  It is therefore intrinsically difficult to use
+   these techniques to discover a consistent translation of the three or
+   four interdependent addresses for the flow and signalling source and
+   destination.
+
+   For legacy NATs and MRMs that carry addressing information, the base
+   GIST specification is therefore limited to detecting the situation
+   and triggering the appropriate error conditions to terminate the
+   signalling path.  (MRMs that do not contain addressing information
+   could traverse such NATs safely, with some modifications to the GIST
+   processing rules.  Such modifications could be described in the
+   documents defining such MRMs.)  Legacy NAT handling is covered in
+   Section 7.2.1 below.  A more general solution can be constructed
+   using GIST-awareness in the NATs themselves; this solution is
+   outlined in Section 7.2.2 with processing rules in Section 7.2.3.
+
+   In all cases, GIST interaction with the NAT is determined by the way
+   the NAT handles the Query/Response messages in the initial GIST
+   handshake; these messages are UDP datagrams.  Best current practice
+   for NAT treatment of UDP traffic is defined in [38], and the legacy
+   NAT handling defined in this specification is fully consistent with
+   that document.  The GIST-aware NAT traversal technique is equivalent
+   to requiring an Application Layer Gateway in the NAT for a specific
+   class of UDP transactions -- namely, those where the destination UDP
+   port for the initial message is the GIST port (see Section 9).
+
+7.2.1.  Legacy NAT Handling
+
+   Legacy NAT detection during the GIST handshake depends on analysis of
+   the IP header and S-flag in the GIST common header, and the NLI
+   object included in the handshake messages.  The message sequence
+   proceeds differently depending on whether the Querying node is on the
+   internal or external side of the NAT.
+
+   For the case of the Querying node on the internal side of the NAT, if
+   the S-flag is not set in the Query (S=0), a legacy NAT cannot be
+   detected.  The receiver will generate a normal Response to the
+   interface-address given in the NLI in the Query, but the interface-
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 94]
+
+RFC 5971                          GIST                      October 2010
+
+
+   address will not be routable and the Response will not be delivered.
+   If retransmitted Queries keep S=0, this behaviour will persist until
+   the Querying node times out.  The signalling path will thus terminate
+   at this point, not traversing the NAT.
+
+   The situation changes once S=1 in a Query; note the Q-mode
+   encapsulation rules recommend that S=1 is used at least for some
+   retransmissions (see Section 5.8).  If S=1, the receiver MUST check
+   the source address in the IP header against the interface-address in
+   the NLI.  A legacy NAT has been found if these addresses do not
+   match.  For MRMs that contain addressing information that needs
+   translation, legacy NAT traversal is not possible.  The receiver MUST
+   return an "Object Type Error" message (Appendix A.4.4.9) with subcode
+   4 ("Untranslated Object") indicating the MRI as the object in
+   question.  The error message MUST be addressed to the source address
+   from the IP header of the incoming message.  The Responding node
+   SHOULD use the destination IP address of the original datagram as the
+   source address for IP header of the Response; this makes it more
+   likely that the NAT will accept the incoming message, since it looks
+   like a normal UDP/IP request/reply exchange.  If this message is able
+   to traverse back through the NAT, the Querying node will terminate
+   the handshake immediately; otherwise, this reduces to the previous
+   case of a lost Response and the Querying node will give up on
+   reaching its retransmission limit.
+
+   When the Querying node is on the external side of the NAT, the Query
+   will only traverse the NAT if some static configuration has been
+   carried out on the NAT to forward GIST Q-mode traffic to a node on
+   the internal network.  Regardless of the S-flag in the Query, the
+   Responding node cannot directly detect the presence of the NAT.  It
+   MUST send a normal Response with S=1 to an address derived from the
+   Querying node's NLI that will traverse the NAT as normal UDP traffic.
+   The Querying node MUST check the source address in the IP header with
+   the NLI in the Response, and when it finds a mismatch it MUST
+   terminate the handshake.
+
+   Note that in either of the error cases (internal or external Querying
+   node), an alternative to terminating the handshake could be to invoke
+   some legacy NAT traversal procedure.  This specification does not
+   define any such procedure, although one possible approach is
+   described in [43].  Any such traversal procedure MUST be incorporated
+   into GIST using the existing GIST extensibility capabilities.  Note
+   also that this detection process only functions with the handshake
+   exchange; it cannot operate on simple Data messages, whether they are
+   Q-mode or normally encapsulated.  Nodes SHOULD NOT send Data messages
+   outside a messaging association if they cannot ensure that they are
+   operating in an environment free of legacy NATs.
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 95]
+
+RFC 5971                          GIST                      October 2010
+
+
+7.2.2.  GIST-Aware NAT Traversal
+
+   The most robust solution to the NAT traversal problem is to require
+   that a NAT is GIST-aware, and to allow it to modify messages based on
+   the contents of the MRI.  This makes the assumption that NATs only
+   rewrite the header fields included in the MRI, and not other higher
+   layer identifiers.  Provided this is done consistently with the data
+   flow header translation, signalling messages can be valid each side
+   of the boundary, without requiring the NAT to be signalling
+   application aware.  Note, however, that if the NAT does not
+   understand the MRI, and the N-flag in the MRI is clear (see
+   Appendix A.3.1), it should reject the message with an "Object Type
+   Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated
+   Object").
+
+   The basic concept is that GIST-aware NATs modify any signalling
+   messages that have to be able to be interpreted without routing state
+   being available; these messages are identified by the context-free
+   flag C=1 in the common header, and include the Query in the GIST
+   handshake.  In addition, NATs have to modify the remaining handshake
+   messages that set up routing state.  When routing state is set up,
+   GIST records how subsequent messages related to that routing state
+   should be translated; if no routing state is being used for a
+   message, GIST directly uses the modifications made by the NAT to
+   translate it.
+
+   This specification defines an additional NAT traversal object that a
+   NAT inserts into all Q-mode encapsulated messages with the context-
+   free flag C=1, and which GIST echoes back in any replies, i.e.,
+   Response or Error messages.  NATs apply GIST-specific processing only
+   to Q-mode encapsulated messages with C=1, or D-mode messages carrying
+   the NAT traversal object.  All other GIST messages, either those in
+   C-mode or those in D-mode with no NAT-Traversal object, should be
+   treated as normal data traffic by the NAT, i.e., with IP and
+   transport layer header translation but no GIST-specific processing.
+   Note that the distinction between Q-mode and D-mode encapsulation may
+   not be observable to the NAT, which is why the setting of the C-flag
+   or presence of the NAT traversal object is used as interception
+   criteria.  The NAT decisions are based purely on the value of the
+   C-flag and the presence of the NAT traversal object, not on the
+   message type.
+
+   The NAT-Traversal object (Appendix A.3.9), carries the translation
+   between the MRIs that are appropriate for the internal and external
+   sides of the NAT.  It also carries a list of which other objects in
+   the message have been translated.  This should always include the
+   NLI, and the Stack-Configuration-Data if present; if GIST is extended
+   with further objects that carry addressing data, this list allows a
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 96]
+
+RFC 5971                          GIST                      October 2010
+
+
+   message receiver to know if the new objects were supported by the
+   NAT.  Finally, the NAT-Traversal object MAY be used to carry data to
+   assist the NAT in back-translating D-mode responses; this could be
+   the original NLI or SCD, or opaque equivalents in the case of
+   topology hiding.
+
+   A consequence of this approach is that the routing state tables at
+   the signalling application peers on each side of the NAT are no
+   longer directly compatible.  In particular, they use different MRI
+   values to refer to the same flow.  However, messages after the Query/
+   Response (the initial Confirm and subsequent Data messages) need to
+   use a common MRI, since the NAT does not rewrite these, and this is
+   chosen to be the MRI of the Querying node.  It is the responsibility
+   of the Responding node to translate between the two MRIs on inbound
+   and outbound messages, which is why the unmodified MRI is propagated
+   in the NAT-Traversal object.
+
+7.2.3.  Message Processing Rules
+
+   This specification normatively defines the behaviour of a GIST node
+   receiving a message containing a NAT-Traversal object.  However, it
+   does not define normative behaviour for a NAT translating GIST
+   messages, since much of this will depend on NAT implementation and
+   policy about allocating bindings.  In addition, it is not necessary
+   for a GIST implementation itself.  Therefore, those aspects of the
+   following description are informative; full details of NAT behaviour
+   for handling GIST messages can be found in [44].
+
+   A possible set of operations for a NAT to process a message with C=1
+   is as follows.  Note that for a Data message, only a subset of the
+   operations is applicable.
+
+   1.  Verify that bindings for any data flow are actually in place.
+
+   2.  Create a new Message-Routing-Information object with fields
+       modified according to the data flow bindings.
+
+   3.  Create bindings for subsequent C-mode signalling based on the
+       information in the Network-Layer-Information and Stack-
+       Configuration-Data objects.
+
+   4.  Create new Network-Layer-Information and if necessary Stack-
+       Configuration-Data objects with fields to force D-mode response
+       messages through the NAT, and to allow C-mode exchanges using the
+       C-mode signalling bindings.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 97]
+
+RFC 5971                          GIST                      October 2010
+
+
+   5.  Add a NAT-Traversal object, listing the objects that have been
+       modified and including the unmodified MRI and any other data
+       needed to interpret the response.  If a NAT-Traversal object is
+       already present, in the case of a sequence of NATs, the list of
+       modified objects may be updated and further opaque data added,
+       but the MRI contained in it is left unchanged.
+
+   6.  Encapsulate the message according to the normal rules of this
+       specification for the Q-mode encapsulation.  If the S-flag was
+       set in the original message, the same IP source address selection
+       policy should be applied to the forwarded message.
+
+   7.  Forward the message with these new payloads.
+
+   A GIST node receiving such a message MUST verify that all mandatory
+   objects containing addressing have been translated correctly, or else
+   reject the message with an "Object Type Error" message
+   (Appendix A.4.4.9) with subcode 4 ("Untranslated Object").  The error
+   message MUST include the NAT-Traversal object as the first TLV after
+   the common header, and this is also true for any other error message
+   generated as a reply.  Otherwise, the message is processed
+   essentially as normal.  If no state needs to be updated for the
+   message, the NAT-Traversal object can be effectively ignored.  The
+   other possibility is that a Response must be returned, because the
+   message is either the beginning of a handshake for a new flow or a
+   refresh for existing state.  In both cases, the GIST node MUST create
+   the Response in the normal way using the local form of the MRI, and
+   its own NLI and (if necessary) SCD.  It MUST also include the NAT-
+   Traversal object as the first object in the Response after the common
+   header.
+
+   A NAT will intercept D-mode messages containing such echoed NAT-
+   Traversal objects.  The NAT processing is a subset of the processing
+   for the C=1 case:
+
+   1.  Verify the existence of bindings for the data flow.
+
+   2.  Leave the Message-Routing-Information object unchanged.
+
+   3.  Modify the NLI and SCD objects for the Responding node if
+       necessary, and create or update any bindings for C-mode
+       signalling traffic.
+
+   4.  Forward the message.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 98]
+
+RFC 5971                          GIST                      October 2010
+
+
+   A GIST node receiving such a message (Response or Error) MUST use the
+   MRI from the NAT-Traversal object as the key to index its internal
+   routing state; it MAY also store the translated MRI for additional
+   (e.g., diagnostic) information, but this is not used in the GIST
+   processing.  The remainder of GIST processing is unchanged.
+
+   Note that Confirm messages are not given GIST-specific processing by
+   the NAT.  Thus, a Responding node that has delayed state installation
+   until receiving the Confirm only has available the untranslated MRI
+   describing the flow, and the untranslated NLI as peer routing state.
+   This would prevent the correct interpretation of the signalling
+   messages; also, subsequent Query (refresh) messages would always be
+   seen as route changes because of the NLI change.  Therefore, a
+   Responding node that wishes to delay state installation until
+   receiving a Confirm must somehow reconstruct the translations when
+   the Confirm arrives.  How to do this is an implementation issue; one
+   approach is to carry the translated objects as part of the Responder-
+   Cookie that is echoed in the Confirm.  Indeed, for one of the cookie
+   constructions in Section 8.5 this is automatic.
+
+7.3.  Interaction with IP Tunnelling
+
+   The interaction between GIST and IP tunnelling is very simple.  An IP
+   packet carrying a GIST message is treated exactly the same as any
+   other packet with the same source and destination addresses: in other
+   words, it is given the tunnel encapsulation and forwarded with the
+   other data packets.
+
+   Tunnelled packets will not be identifiable as GIST messages until
+   they leave the tunnel, since any Router Alert Option and the standard
+   GIST protocol encapsulation (e.g., port numbers) will be hidden
+   within the standard tunnel encapsulation.  If signalling is needed
+   for the tunnel itself, this has to be initiated as a separate
+   signalling session by one of the tunnel endpoints -- that is, the
+   tunnel counts as a new flow.  Because the relationship between
+   signalling for the microflow and signalling for the tunnel as a whole
+   will depend on the signalling application in question, it is a
+   signalling application responsibility to be aware of the fact that
+   tunnelling is taking place and to carry out additional signalling if
+   necessary; in other words, at least one tunnel endpoint must be
+   signalling application aware.
+
+   In some cases, it is the tunnel exit point (i.e., the node where
+   tunnelled data and downstream signalling packets leave the tunnel)
+   that will wish to carry out the tunnel signalling, but this node will
+   not have knowledge or control of how the tunnel entry point is
+   carrying out the data flow encapsulation.  The information about how
+   the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in
+
+
+
+Schulzrinne & Hancock         Experimental                     [Page 99]
+
+RFC 5971                          GIST                      October 2010
+
+
+   the signalling data from the tunnel entry point; this functionality
+   is the equivalent to the RSVP SESSION_ASSOC object of [18].  In the
+   NSIS protocol suite, these bindings are managed by the signalling
+   applications, either implicitly (e.g., by SID re-use) or explicitly
+   by carrying objects that bind the inner and outer SIDs as part of the
+   NSLP payload.
+
+7.4.  IPv4-IPv6 Transition and Interworking
+
+   GIST itself is essentially IP version neutral: version dependencies
+   are isolated in the formats of the Message-Routing-Information,
+   Network-Layer-Information, and Stack-Configuration-Data objects, and
+   GIST also depends on the version independence of the protocols that
+   support messaging associations.  In mixed environments, GIST
+   operation will be influenced by the IP transition mechanisms in use.
+   This section provides a high level overview of how GIST is affected,
+   considering only the currently predominant mechanisms.
+
+   Dual Stack:  (As described in [35].)  In mixed environments, GIST
+      MUST use the same IP version for Q-mode encapsulated messages as
+      given by the MRI of the flow for which it is signalling, and
+      SHOULD do so for other signalling also (see Section 5.2.2).
+      Messages with mismatching versions MUST be rejected with an "MRI
+      Validation Failure" error message (Appendix A.4.4.12) with subcode
+      1 ("IP Version Mismatch").  The IP version used in D-mode is
+      closely tied to the IP version used by the data flow, so it is
+      intrinsically impossible for an IPv4-only or IPv6-only GIST node
+      to support signalling for flows using the other IP version.  Hosts
+      that are dual stack for applications and routers that are dual
+      stack for forwarding need GIST implementations that can support
+      both IP versions.  Applications with a choice of IP versions might
+      select a version based on which could be supported in the network
+      by GIST, which could be established by invoking parallel discovery
+      procedures.
+
+   Packet Translation:  (Applicable to SIIT [7].)  Some transition
+      mechanisms allow IPv4 and IPv6 nodes to communicate by placing
+      packet translators between them.  From the GIST perspective, this
+      should be treated essentially the same way as any other NAT
+      operation (e.g., between internal and external addresses) as
+      described in Section 7.2.  The translating node needs to be GIST-
+      aware; it will have to translate the addressing payloads between
+      IPv4 and IPv6 formats for flows that cross between the two.  The
+      translation rules for the fields in the MRI payload (including,
+      e.g., diffserv-codepoint and flow-label) are as defined in [7].
+      The same analysis applies to NAT-PT, although this technique is no
+      longer proposed as a general purpose transition mechanism [40].
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 100]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Tunnelling:  (Applicable to 6to4 [19].)  Many transition mechanisms
+      handle the problem of how an end-to-end IPv6 (or IPv4) flow can be
+      carried over intermediate IPv4 (or IPv6) regions by tunnelling;
+      the methods tend to focus on minimising the tunnel administration
+      overhead.  For GIST, the treatment should be similar to any other
+      IP tunnelling mechanism, as described in Section 7.3.  In
+      particular, the end-to-end flow signalling will pass transparently
+      through the tunnel, and signalling for the tunnel itself will have
+      to be managed by the tunnel endpoints.  However, additional
+      considerations may arise because of special features of the tunnel
+      management procedures.  In particular, [20] is based on using an
+      anycast address as the destination tunnel endpoint.  GIST MAY use
+      anycast destination addresses in the Q-mode encapsulation of
+      D-mode messages if necessary, but MUST NOT use them in the
+      Network-Layer-Information addressing field; unicast addresses MUST
+      be used instead.  Note that the addresses from the IP header are
+      not used by GIST in matching requests and replies, so there is no
+      requirement to use anycast source addresses.
+
+8.  Security Considerations
+
+   The security requirement for GIST is to protect the signalling plane
+   against identified security threats.  For the signalling problem as a
+   whole, these threats have been outlined in [30]; the NSIS framework
+   [29] assigns a subset of the responsibilities to the NTLP.  The main
+   issues to be handled can be summarised as:
+
+   Message Protection:  Signalling message content can be protected
+      against eavesdropping, modification, injection, and replay while
+      in transit.  This applies to GIST payloads, and GIST should also
+      provide such protection as a service to signalling applications
+      between adjacent peers.
+
+   Routing State Integrity Protection:  It is important that signalling
+      messages are delivered to the correct nodes, and nowhere else.
+      Here, 'correct' is defined as 'the appropriate nodes for the
+      signalling given the Message-Routing-Information'.  In the case
+      where the MRI is based on the flow identification for path-coupled
+      signalling, 'appropriate' means 'the same nodes that the
+      infrastructure will route data flow packets through'.  GIST has no
+      role in deciding whether the data flow itself is being routed
+      correctly; all it can do is to ensure that signalling and data
+      routing are consistent with each other.  GIST uses internal state
+      to decide how to route signalling messages, and this state needs
+      to be protected against corruption.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 101]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Prevention of Denial-of-Service Attacks:  GIST nodes and the network
+      have finite resources (state storage, processing power,
+      bandwidth).  The protocol tries to minimise exhaustion attacks
+      against these resources and not allow GIST nodes to be used to
+      launch attacks on other network elements.
+
+   The main additional issue is handling authorisation for executing
+   signalling operations (e.g., allocating resources).  This is assumed
+   to be done in each signalling application.
+
+   In many cases, GIST relies on the security mechanisms available in
+   messaging associations to handle these issues, rather than
+   introducing new security measures.  Obviously, this requires the
+   interaction of these mechanisms with the rest of the GIST protocol to
+   be understood and verified, and some aspects of this are discussed in
+   Section 5.7.
+
+8.1.  Message Confidentiality and Integrity
+
+   GIST can use messaging association functionality, specifically in
+   this version TLS (Section 5.7.3), to ensure message confidentiality
+   and integrity.  Implementation of this functionality is REQUIRED but
+   its use for any given flow or signalling application is OPTIONAL.  In
+   some cases, confidentiality of GIST information itself is not likely
+   to be a prime concern, in particular, since messages are often sent
+   to parties that are unknown ahead of time, although the content
+   visible even at the GIST level gives significant opportunities for
+   traffic analysis.  Signalling applications may have their own
+   mechanism for securing content as necessary; however, they may find
+   it convenient to rely on protection provided by messaging
+   associations, since it runs unbroken between signalling application
+   peers.
+
+8.2.  Peer Node Authentication
+
+   Cryptographic protection (of confidentiality or integrity) requires a
+   security association with session keys.  These can be established by
+   an authentication and key exchange protocol based on shared secrets,
+   public key techniques, or a combination of both.  Authentication and
+   key agreement are possible using the protocols associated with the
+   messaging association being secured.  TLS incorporates this
+   functionality directly.  GIST nodes rely on the messaging association
+   protocol to authenticate the identity of the next hop, and GIST has
+   no authentication capability of its own.
+
+   With routing state discovery, there are few effective ways to know
+   what is the legitimate next or previous hop as opposed to an
+   impostor.  In other words, cryptographic authentication here only
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 102]
+
+RFC 5971                          GIST                      October 2010
+
+
+   provides assurance that a node is 'who' it is (i.e., the legitimate
+   owner of identity in some namespace), not 'what' it is (i.e., a node
+   which is genuinely on the flow path and therefore can carry out
+   signalling for a particular flow).  Authentication provides only
+   limited protection, in that a known peer is unlikely to lie about its
+   role.  Additional methods of protection against this type of attack
+   are considered in Section 8.3 below.
+
+   It is an implementation issue whether peer node authentication should
+   be made signalling application dependent, for example, whether
+   successful authentication could be made dependent on presenting
+   credentials related to a particular signalling role (e.g., signalling
+   for QoS).  The abstract API of Appendix B leaves open such policy and
+   authentication interactions between GIST and the NSLP it is serving.
+   However, it does allow applications to inspect the authenticated
+   identity of the peer to which a message will be sent before
+   transmission.
+
+8.3.  Routing State Integrity
+
+   Internal state in a node (see Section 4.2) is used to route messages.
+   If this state is corrupted, signalling messages may be misdirected.
+
+   In the case where the MRM is path-coupled, the messages need to be
+   routed identically to the data flow described by the MRI, and the
+   routing state table is the GIST view of how these flows are being
+   routed through the network in the immediate neighbourhood of the
+   node.  Routes are only weakly secured (e.g., there is no
+   cryptographic binding of a flow to a route), and there is no
+   authoritative information about flow routes other than the current
+   state of the network itself.  Therefore, consistency between GIST and
+   network routing state has to be ensured by directly interacting with
+   the IP routing mechanisms to ensure that the signalling peers are the
+   appropriate ones for any given flow.  An overview of security issues
+   and techniques in this context is provided in [37].
+
+   In one direction, peer identification is installed and refreshed only
+   on receiving a Response (compare Figure 5).  This MUST echo the
+   cookie from a previous Query, which will have been sent along the
+   flow path with the Q-mode encapsulation, i.e., end-to-end addressed.
+   Hence, only the true next peer or an on-path attacker will be able to
+   generate such a message, provided freshness of the cookie can be
+   checked at the Querying node.
+
+   In the other direction, peer identification MAY be installed directly
+   on receiving a Query containing addressing information for the
+   signalling source.  However, any node in the network could generate
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 103]
+
+RFC 5971                          GIST                      October 2010
+
+
+   such a message; indeed, many nodes in the network could be the
+   genuine upstream peer for a given flow.  To protect against this,
+   four strategies are used:
+
+   Filtering:  The receiving node MAY reject signalling messages that
+      claim to be for flows with flow source addresses that could be
+      ruled out by ingress filtering.  An extension of this technique
+      would be for the receiving node to monitor the data plane and to
+      check explicitly that the flow packets are arriving over the same
+      interface and if possible from the same link layer neighbour as
+      the D-mode signalling packets.  If they are not, it is likely that
+      at least one of the signalling or flow packets is being spoofed.
+
+   Return routability checking:  The receiving node MAY refuse to
+      install upstream state until it has completed a Confirm handshake
+      with the peer.  This echoes the Responder-Cookie of the Response,
+      and discourages nodes from using forged source addresses.  This
+      also plays a role in denial-of-service prevention; see below.
+
+   Authorisation:  A stronger approach is to carry out a peer
+      authorisation check (see Section 4.4.2) as part of messaging
+      association setup.  The ideal situation is that the receiving node
+      can determine the correct upstream node address from routing table
+      analysis or knowledge of local topology constraints, and then
+      verify from the authorised peer database (APD) that the peer has
+      this IP address.  This is only technically feasible in a limited
+      set of deployment environments.  The APD can also be used to list
+      the subsets of nodes that are feasible peers for particular source
+      or destination subnets, or to blacklist nodes that have previously
+      originated attacks or exist in untrustworthy networks, which
+      provide weaker levels of authorisation checking.
+
+   SID segregation:  The routing state lookup for a given MRI and NSLPID
+      MUST also take the SID into account.  A malicious node can only
+      overwrite existing GIST routing state if it can guess the
+      corresponding SID; it can insert state with random SID values, but
+      generally this will not be used to route signalling messages for
+      which state has already been legitimately established.
+
+8.4.  Denial-of-Service Prevention and Overload Protection
+
+   GIST is designed so that in general each Query only generates at most
+   one Response that is at most only slightly larger than the Query, so
+   that a GIST node cannot become the source of a denial-of-service
+   amplification attack.  (There is a special case of retransmitted
+   Response messages; see Section 5.3.3.)
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 104]
+
+RFC 5971                          GIST                      October 2010
+
+
+   However, GIST can still be subjected to denial-of-service attacks
+   where an attacker using forged source addresses forces a node to
+   establish state without return routability, causing a problem similar
+   to TCP SYN flood attacks.  Furthermore, an adversary might use
+   modified or replayed unprotected signalling messages as part of such
+   an attack.  There are two types of state attacks and one
+   computational resource attack.  In the first state attack, an
+   attacker floods a node with messages that the node has to store until
+   it can determine the next hop.  If the destination address is chosen
+   so that there is no GIST-capable next hop, the node would accumulate
+   messages for several seconds until the discovery retransmission
+   attempt times out.  The second type of state-based attack causes GIST
+   state to be established by bogus messages.  A related computational/
+   network-resource attack uses unverified messages to cause a node
+   query an authentication or authorisation infrastructure, or attempt
+   to cryptographically verify a digital signature.
+
+   We use a combination of two defences against these attacks:
+
+   1.  The Responding node need not establish a session or discover its
+       next hop on receiving the Query, but MAY wait for a Confirm,
+       possibly on a secure channel.  If the channel exists, the
+       additional delay is one one-way delay and the total is no more
+       than the minimal theoretically possible delay of a three-way
+       handshake, i.e., 1.5 node-to-node round-trip times.  The delay
+       gets significantly larger if a new connection needs to be
+       established first.
+
+   2.  The Response to the Query contains a cookie, which is repeated in
+       the Confirm.  State is only established for messages that contain
+       a valid cookie.  The setup delay is also 1.5 round-trip times.
+       This mechanism is similar to that in SCTP [39] and other modern
+       protocols.
+
+   There is a potential overload condition if a node is flooded with
+   Query or Confirm messages.  One option is for the node to bypass
+   these messages altogether as described in Section 4.3.2, effectively
+   falling back to being a non-NSIS node.  If this is not possible, a
+   node MAY still choose to limit the rate at which it processes Query
+   messages and discard the excess, although it SHOULD first adapt its
+   policy to one of sending Responses statelessly if it is not already
+   doing so.  A conformant GIST node will automatically decrease the
+   load by retransmitting Queries with an exponential backoff.  A non-
+   conformant node (launching a DoS attack) can generate uncorrelated
+   Queries at an arbitrary rate, which makes it hard to apply rate-
+   limiting without also affecting genuine handshake attempts.  However,
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 105]
+
+RFC 5971                          GIST                      October 2010
+
+
+   if Confirm messages are requested, the cookie binds the message to a
+   Querying node address that has been validated by a return routability
+   check and rate-limits can be applied per source.
+
+   Once a node has decided to establish routing state, there may still
+   be transport and security state to be established between peers.
+   This state setup is also vulnerable to denial-of-service attacks.
+   GIST relies on the implementations of the lower layer protocols that
+   make up messaging associations to mitigate such attacks.  In the
+   current specification, the Querying node is always the one wishing to
+   establish a messaging association, so it is the Responding node that
+   needs to be protected.  It is possible for an attacking node to
+   execute these protocols legally to set up large numbers of
+   associations that were never used, and Responding node
+   implementations MAY use rate-limiting or other techniques to control
+   the load in such cases.
+
+   Signalling applications can use the services provided by GIST to
+   defend against certain (e.g., flooding) denial-of-service attacks.
+   In particular, they can elect to process only messages from peers
+   that have passed a return routability check or been authenticated at
+   the messaging association level (see Appendix B.2).  Signalling
+   applications that accept messages under other circumstances (in
+   particular, before routing state has been fully established at the
+   GIST level) need to take this into account when designing their
+   denial-of-service prevention mechanisms, for example, by not creating
+   local state as a result of processing such messages.  Signalling
+   applications can also manage overload by invoking flow control, as
+   described in Section 4.1.1.
+
+8.5.  Requirements on Cookie Mechanisms
+
+   The requirements on the Query-Cookie can be summarised as follows:
+
+   Liveness:  The cookie must be live; that is, it must change from one
+      handshake to the next.  This prevents replay attacks.
+
+   Unpredictability:  The cookie must not be guessable, e.g., from a
+      sequence or timestamp.  This prevents direct forgery after
+      capturing a set of earlier messages.
+
+   Easily validated:  It must be efficient for the Q-Node to validate
+      that a particular cookie matches an in-progress handshake, for a
+      routing state machine that already exists.  This allows to discard
+      responses that have been randomly generated by an adversary, or to
+      discard responses to queries that were generated with forged
+      source addresses or an incorrect address in the included NLI
+      object.
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 106]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Uniqueness:  Each handshake must have a unique cookie since the
+      cookie is used to match responses within a handshake, e.g., when
+      multiple messaging associations are multiplexed over the same
+      transport connection.
+
+   Likewise, the requirements on the Responder-Cookie can be summarised
+   as follows:
+
+   Liveness:  The cookie must be live as above, to prevent replay
+      attacks.
+
+   Creation simplicity:  The cookie must be lightweight to generate in
+      order to avoid resource exhaustion at the responding node.
+
+   Validation simplicity:  It must be simple for the R-node to validate
+      that an R-Cookie was generated by itself and no one else, without
+      storing state about the handshake for which it was generated.
+
+   Binding:  The cookie must be bound to the routing state that will be
+      installed, to prevent use with different routing state, e.g., in a
+      modified Confirm.  The routing state here includes the Peer-
+      Identity and Interface-Address given in the NLI of the Query, and
+      the MRI/NSLPID for the messaging.
+
+      It can also include the interface on which the Query was received
+      for use later in route change detection (Section 7.1.2).  Since a
+      Q-mode encapsulated message is the one that will best follow the
+      data path, subsequent changes in this arrival interface indicate
+      route changes between the peers.
+
+   A suitable implementation for the Q-Cookie is a cryptographically
+   strong random number that is unique for this routing state machine
+   handshake.  A node MUST implement this or an equivalently strong
+   mechanism.  Guidance on random number generation can be found in
+   [31].
+
+   A suitable basic implementation for the R-Cookie is as follows:
+
+        R-Cookie = liveness data + reception interface
+                   + hash (locally known secret,
+                           Q-Node NLI identity and address, MRI, NSLPID,
+                           liveness data)
+
+   A node MUST implement this or an equivalently strong mechanism.
+   There are several alternatives for the liveness data.  One is to use
+   a timestamp like SCTP.  Another is to give the local secret a (rapid)
+   rollover, with the liveness data as the generation number of the
+   secret, like IKEv2.  In both cases, the liveness data has to be
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 107]
+
+RFC 5971                          GIST                      October 2010
+
+
+   carried outside the hash, to allow the hash to be verified at the
+   Responder.  Another approach is to replace the hash with encryption
+   under a locally known secret, in which case the liveness data does
+   not need to be carried in the clear.  Any symmetric cipher immune to
+   known plaintext attacks can be used.  In the case of GIST-aware NAT
+   traversal with delayed state installation, it is necessary to carry
+   additional data in the cookie; appropriate constructions are
+   described in [44].
+
+   To support the validation simplicity requirement, the Responder can
+   check the liveness data to filter out some blind (flooding) attacks
+   before beginning any cryptographic cookie verification.  To support
+   this usage, the liveness data must be carried in the clear and not be
+   easily guessable; this rules out the timestamp approach and suggests
+   the use of sequence of secrets with the liveness data identifying the
+   position in the sequence.  The secret strength and rollover frequency
+   must be high enough that the secret cannot be brute-forced during its
+   lifetime.  Note that any node can use a Query to discover the current
+   liveness data, so it remains hard to defend against sophisticated
+   attacks that disguise such probes within a flood of Queries from
+   forged source addresses.  Therefore, it remains important to use an
+   efficient hashing mechanism or equivalent.
+
+   If a node receives a message for which cookie validation fails, it
+   MAY return an "Object Value Error" message (Appendix A.4.4.10) with
+   subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error
+   condition locally, as well as dropping the message.  However, sending
+   the error in general makes a node a source of backscatter.
+   Therefore, this MUST only be enabled selectively, e.g., during
+   initial deployment or debugging.
+
+8.6.  Security Protocol Selection Policy
+
+   This specification defines a single mandatory-to-implement security
+   protocol (TLS; Section 5.7.3).  However, it is possible to define
+   additional security protocols in the future, for example, to allow
+   re-use with other types of credentials, or migrate towards protocols
+   with stronger security properties.  In addition, use of any security
+   protocol for a messaging association is optional.  Security protocol
+   selection is carried out as part of the GIST handshake mechanism
+   (Section 4.4.1).
+
+   The selection process may be vulnerable to downgrade attacks, where a
+   man in the middle modifies the capabilities offered in the Query or
+   Response to mislead the peers into accepting a lower level of
+   protection than is achievable.  There is a two-part defence against
+   such attacks (the following is based the same concepts as [25]):
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 108]
+
+RFC 5971                          GIST                      October 2010
+
+
+   1.  The Response does not depend on the Stack-Proposal in the Query
+       (see Section 5.7.1).  Therefore, tampering with the Query has no
+       effect on the resulting messaging association configuration.
+
+   2.  The Responding node's Stack-Proposal is echoed in the Confirm.
+       The Responding node checks this to validate that the proposal it
+       made in the Response is the same as the one received by the
+       Querying node.  Note that as a consequence of the previous point,
+       the Responding node does not have to remember the proposal
+       explicitly, since it is a static function of local policy.
+
+   The validity of the second part depends on the strength of the
+   security protection provided for the Confirm.  If the Querying node
+   is prepared to create messaging associations with null security
+   properties (e.g., TCP only), the defence is ineffective, since the
+   man in the middle can re-insert the original Responder's Stack-
+   Proposal, and the Responding node will assume that the minimal
+   protection is a consequence of Querying node limitations.  However,
+   if the messaging association provides at least integrity protection
+   that cannot be broken in real-time, the Confirm cannot be modified in
+   this way.  Therefore, if the Querying node does not apply a security
+   policy to the messaging association protocols to be created that
+   ensures at least this minimal level of protection is met, it remains
+   open to the threat that a downgrade has occurred.  Applying such a
+   policy ensures capability discovery process will result in the setup
+   of a messaging association with the correct security properties for
+   the two peers involved.
+
+8.7.  Residual Threats
+
+   Taking the above security mechanisms into account, the main residual
+   threats against NSIS are three types of on-path attack,
+   vulnerabilities from particular limited modes of TLS usage, and
+   implementation-related weaknesses.
+
+   An on-path attacker who can intercept the initial Query can do most
+   things it wants to the subsequent signalling.  It is very hard to
+   protect against this at the GIST level; the only defence is to use
+   strong messaging association security to see whether the Responding
+   node is authorised to take part in NSLP signalling exchanges.  To
+   some extent, this behaviour is logically indistinguishable from
+   correct operation, so it is easy to see why defence is difficult.
+   Note that an on-path attacker of this sort can do anything to the
+   traffic as well as the signalling.  Therefore, the additional threat
+   induced by the signalling weakness seems tolerable.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 109]
+
+RFC 5971                          GIST                      October 2010
+
+
+   At the NSLP level, there is a concern about transitivity of trust of
+   correctness of routing along the signalling chain.  The NSLP at the
+   querying node can have good assurance that it is communicating with
+   an on-path peer or a node delegated by the on-path node by depending
+   on the security protection provided by GIST.  However, it has no
+   assurance that the node beyond the responder is also on-path, or that
+   the MRI (in particular) is not being modified by the responder to
+   refer to a different flow.  Therefore, if it sends signalling
+   messages with payloads (e.g., authorisation tokens) that are valuable
+   to nodes beyond the adjacent hop, it is up to the NSLP to ensure that
+   the appropriate chain of trust exists.  This could be achieved using
+   higher layer security protection such as Cryptographic Message Syntax
+   (CMS) [28].
+
+   There is a further residual attack by a node that is not on the path
+   of the Query, but is on the path of the Response, or is able to use a
+   Response from one handshake to interfere with another.  The attacker
+   modifies the Response to cause the Querying node to form an adjacency
+   with it rather than the true peer.  In principle, this attack could
+   be prevented by including an additional cryptographic object in the
+   Response that ties the Response to the initial Query and the routing
+   state and can be verified by the Querying node.
+
+   GIST depends on TLS for peer node authentication, and subsequent
+   channel security.  The analysis in [30] indicates the threats that
+   arise when the peer node authentication is incomplete --
+   specifically, when unilateral authentication is performed (one node
+   authenticates the other, but not vice versa).  In this specification,
+   mutual authentication can be supported either by certificate exchange
+   or the use of pre-shared keys (see Section 5.7.3); if some other TLS
+   authentication mechanism is negotiated, its properties would have to
+   be analysed to determine acceptability for use with GIST.  If mutual
+   authentication is performed, the requirements for NTLP security are
+   met.
+
+   However, in the case of certificate exchange, this specification
+   allows the possibility that only a server certificate is provided,
+   which means that the Querying node authenticates the Responding node
+   but not vice versa.  Accepting such unilateral authentication allows
+   for partial security in environments where client certificates are
+   not widespread, and is better than no security at all; however, it
+   does expose the Responding node to certain threats described in
+   Section 3.1 of [30].  For example, the Responding node cannot verify
+   whether there is a man-in-the-middle between it and the Querying
+   node, which could be manipulating the signalling messages, and it
+   cannot verify the identity of the Querying node if it requests
+   authorisation of resources.  Note that in the case of host-network
+   signalling, the Responding node could be either the host or the first
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 110]
+
+RFC 5971                          GIST                      October 2010
+
+
+   hop router, depending on the signalling direction.  Because of these
+   vulnerabilities, modes or deployments of TLS which do not provide
+   mutual authentication can be considered as at best transitional
+   stages rather than providing a robust security solution.
+
+   Certain security aspects of GIST operation depend on signalling
+   application behaviour: a poorly implemented or compromised NSLP could
+   degrade GIST security.  However, the degradation would only affect
+   GIST handling of the NSLP's own signalling traffic or overall
+   resource usage at the node where the weakness occurred, and
+   implementation weakness or compromise could have just as great an
+   effect within the NSLP itself.  GIST depends on NSLPs to choose SIDs
+   appropriately (Section 4.1.3).  If NSLPs choose non-random SIDs, this
+   makes off-path attacks based on SID guessing easier to carry out.
+   NSLPs can also leak information in structured SIDs, but they could
+   leak similar information in the NSLP payload data anyway.
+
+9.  IANA Considerations
+
+   This section defines the registries and initial codepoint assignments
+   for GIST.  It also defines the procedural requirements to be followed
+   by IANA in allocating new codepoints.  Note that the guidelines on
+   the technical criteria to be followed in evaluating requests for new
+   codepoint assignments are covered normatively in a separate document
+   that considers the NSIS protocol suite in a unified way.  That
+   document discusses the general issue of NSIS extensibility, as well
+   as the technical criteria for particular registries; see [12] for
+   further details.
+
+   The registry definitions that follow leave large blocks of codes
+   marked "Reserved".  This is to allow a future revision of this
+   specification or another Experimental document to modify the relative
+   space given to different allocation policies, without having to
+   change the initial rules retrospectively if they turn out to have
+   been inappropriate, e.g., if the space for one particular policy is
+   exhausted too quickly.
+
+   The allocation policies used in this section follow the guidance
+   given in [4].  In addition, for a number of the GIST registries, this
+   specification also defines private/experimental ranges as discussed
+   in [9].  Note that the only environment in which these codepoints can
+   validly be used is a closed one in which the experimenter knows all
+   the experiments in progress.
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 111]
+
+RFC 5971                          GIST                      October 2010
+
+
+   This specification allocates the following codepoints in existing
+   registries:
+
+      Well-known UDP port 270 as the destination port for Q-mode
+      encapsulated GIST messages (Section 5.3).
+
+   This specification creates the following registries with the
+   structures as defined below:
+
+   NSLP Identifiers:  Each signalling application requires the
+      assignment of one or more NSLPIDs.  The following NSLPID is
+      allocated by this specification:
+
+   +---------+---------------------------------------------------------+
+   | NSLPID  | Application                                             |
+   +---------+---------------------------------------------------------+
+   | 0       | Used for GIST messages not related to any signalling    |
+   |         | application.                                            |
+   +---------+---------------------------------------------------------+
+
+      Every other NSLPID that uses an MRM that requires RAO usage MUST
+      be associated with a specific RAO value; multiple NSLPIDs MAY be
+      associated with the same RAO value.  RAO value assignments require
+      a specification of the processing associated with messages that
+      carry the value.  NSLP specifications MUST normatively depend on
+      this document for the processing, specifically Sections 4.3.1,
+      4.3.4 and 5.3.2.  The NSLPID is a 16-bit integer, and the
+      registration procedure is IESG Aproval.  Further values are as
+      follows:
+
+      1-32703:  Unassigned
+
+      32704-32767:  Private/Experimental Use
+
+      32768-65536:  Reserved
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 112]
+
+RFC 5971                          GIST                      October 2010
+
+
+   GIST Message Type:  The GIST common header (Appendix A.1) contains a
+      7-bit message type field.  The following values are allocated by
+      this specification:
+
+                          +---------+----------+
+                          | MType   | Message  |
+                          +---------+----------+
+                          | 0       | Query    |
+                          |         |          |
+                          | 1       | Response |
+                          |         |          |
+                          | 2       | Confirm  |
+                          |         |          |
+                          | 3       | Data     |
+                          |         |          |
+                          | 4       | Error    |
+                          |         |          |
+                          | 5       | MA-Hello |
+                          +---------+----------+
+
+      Registration procedures are as follows:
+
+      0-31:  IETF Review
+
+      32-55:  Expert Review
+
+      Further values are as follows:
+
+      6-55:  Unassigned
+
+      56-63:  Private/Experimental Use
+
+      64-127:  Reserved
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 113]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Object Types:  There is a 12-bit field in the object header
+      (Appendix A.2).  The following values for object type are defined
+      by this specification:
+
+                 +---------+-----------------------------+
+                 | OType   | Object Type                 |
+                 +---------+-----------------------------+
+                 | 0       | Message Routing Information |
+                 |         |                             |
+                 | 1       | Session ID                  |
+                 |         |                             |
+                 | 2       | Network Layer Information   |
+                 |         |                             |
+                 | 3       | Stack Proposal              |
+                 |         |                             |
+                 | 4       | Stack Configuration Data    |
+                 |         |                             |
+                 | 5       | Query-Cookie                |
+                 |         |                             |
+                 | 6       | Responder-Cookie            |
+                 |         |                             |
+                 | 7       | NAT Traversal               |
+                 |         |                             |
+                 | 8       | NSLP Data                   |
+                 |         |                             |
+                 | 9       | Error                       |
+                 |         |                             |
+                 | 10      | Hello ID                    |
+                 +---------+-----------------------------+
+
+      Registration procedures are as follows:
+
+      0-1023:  IETF Review
+
+      1024-1999:  Specification Required
+
+      Further values are as follows:
+
+      11-1999:  Unassigned
+
+      2000-2047:  Private/Experimental Use
+
+      2048-4095:  Reserved
+
+      When a new object type is allocated according to one of the
+      procedures, the specification MUST provide the object format and
+      define the setting of the extensibility bits (A/B; see
+      Appendix A.2.1).
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 114]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Message Routing Methods:  GIST allows multiple message routing
+      methods (see Section 3.3).  The MRM is indicated in the leading
+      byte of the MRI object (Appendix A.3.1).  This specification
+      defines the following values:
+
+                  +------------+------------------------+
+                  | MRM-ID     | Message Routing Method |
+                  +------------+------------------------+
+                  | 0          | Path-Coupled MRM       |
+                  |            |                        |
+                  | 1          | Loose-End MRM          |
+                  +------------+------------------------+
+
+      Registration procedures are as follows:
+
+      0-63:  IETF Review
+
+      64-119:  Specification Required
+
+      Further values are as follows:
+
+      2-119:  Unassigned
+
+      120-127:  Private/Experimental Use
+
+      128-255:  Reserved
+
+      When a new MRM is allocated according to one of the registration
+      procedures, the specification MUST provide the information
+      described in Section 3.3.
+
+   MA-Protocol-IDs:  Each protocol that can be used in a messaging
+      association is identified by a 1-byte MA-Protocol-ID
+      (Section 5.7).  Note that the MA-Protocol-ID is not an IP protocol
+      number; indeed, some of the messaging association protocols --
+      such as TLS -- do not have an IP protocol number.  This is used as
+      a tag in the Stack-Proposal and Stack-Configuration-Data objects
+      (Appendix A.3.4 and Appendix A.3.5).  The following values are
+      defined by this specification:
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 115]
+
+RFC 5971                          GIST                      October 2010
+
+
+     +---------------------+-----------------------------------------+
+     | MA-Protocol-ID      | Protocol                                |
+     +---------------------+-----------------------------------------+
+     | 0                   | Reserved                                |
+     |                     |                                         |
+     | 1                   | TCP opened in the forwards direction    |
+     |                     |                                         |
+     | 2                   | TLS initiated in the forwards direction |
+     +---------------------+-----------------------------------------+
+
+      Registration procedures are as follows:
+
+      0-63:  IETF Review
+
+      64-119:  Expert Review
+
+      Further values are as follows:
+
+      3-119:  Unassigned
+
+      120-127:  Private/Experimental Use
+
+      128-255:  Reserved
+
+      When a new MA-Protocol-ID is allocated according to one of the
+      registration procedures, a specification document will be
+      required.  This MUST define the format for the MA-protocol-options
+      field (if any) in the Stack-Configuration-Data object that is
+      needed to define its configuration.  If a protocol is to be used
+      for reliable message transfer, it MUST be described how delivery
+      errors are to be detected by GIST.  Extensions to include new
+      channel security protocols MUST include a description of how to
+      integrate the functionality described in Section 3.9 with the rest
+      of GIST operation.  If the new MA-Protocol-ID can be used in
+      conjunction with existing ones (for example, a new transport
+      protocol that could be used with Transport Layer Security), the
+      specification MUST define the interaction between the two.
+
+   Error Codes/Subcodes:  There is a 2-byte error code and 1-byte
+      subcode in the Value field of the Error Object (Appendix A.4.1).
+      Error codes 1-12 are defined in Appendix A.4.4 together with
+      subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code
+      12).  Additional codes and subcodes are allocated on a first-come,
+      first-served basis.  When a new code/subcode combination is
+      allocated, the following information MUST be provided:
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 116]
+
+RFC 5971                          GIST                      October 2010
+
+
+      Error case:  textual name of error
+
+      Error class:  from the categories given in Appendix A.4.3
+
+      Error code:  allocated by IANA, if a new code is required
+
+      Error subcode:  subcode point, also allocated by IANA
+
+      Additional information:  what Additional Information fields are
+         mandatory to include in the error message, from Appendix A.4.2
+
+   Additional Information Types:  An Error Object (Appendix A.4.1) may
+      contain Additional Information fields.  Each possible field type
+      is identified by a 16-bit AI-Type.  AI-Types 1-4 are defined in
+      Appendix A.4.2; additional AI-Types are allocated on a first-come,
+      first-served basis.
+
+10.  Acknowledgements
+
+   This document is based on the discussions within the IETF NSIS
+   working group.  It has been informed by prior work and formal and
+   informal inputs from: Cedric Aoun, Attila Bader, Vitor Bernado,
+   Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko
+   Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann,
+   Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor
+   Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia
+   Kappler, Georgios Karagiannis, Ruud Klaver, Max Laier, Chris Lang,
+   Lauri Liuhto, John Loughney, Allison Mankin, Jukka Manner, Pete
+   McCann, Andrew McDonald, Mac McTiffin, Glenn Morrow, Dave Oran,
+   Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako
+   Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn
+   Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Nuutti
+   Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon.  Parts
+   of the TLS usage description (Section 5.7.3) were derived from the
+   Diameter base protocol specification, RFC 3588.  In addition, Hannes
+   Tschofenig provided a detailed set of review comments on the security
+   section, and Andrew McDonald provided the formal description for the
+   initial packet formats and the name matching algorithm for TLS.
+   Chris Lang's implementation work provided objective feedback on the
+   clarity and feasibility of the specification, and he also provided
+   the state machine description and the initial error catalogue and
+   formats.  Magnus Westerlund carried out a detailed AD review that
+   identified a number of issues and led to significant clarifications,
+   which was followed by an even more detailed IESG review, with
+   comments from Jari Arkko, Ross Callon, Brian Carpenter, Lisa
+   Dusseault, Lars Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 117]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Jennings, and Tim Polk, and a very detailed analysis by Adrian Farrel
+   from the Routing Area directorate; Suresh Krishnan carried out a
+   detailed review for the Gen-ART.
+
+11.  References
+
+11.1.  Normative References
+
+   [1]   Braden, R., "Requirements for Internet Hosts - Communication
+         Layers", STD 3, RFC 1122, October 1989.
+
+   [2]   Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
+         June 1995.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+   [6]   Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
+         the Differentiated Services Field (DS Field) in the IPv4 and
+         IPv6 Headers", RFC 2474, December 1998.
+
+   [7]   Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
+         RFC 2765, February 2000.
+
+   [8]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
+         R., and W. Polk, "Internet X.509 Public Key Infrastructure
+         Certificate and Certificate Revocation List (CRL) Profile",
+         RFC 5280, May 2008.
+
+   [9]   Narten, T., "Assigning Experimental and Testing Numbers
+         Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [10]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+         Protocol Version 1.2", RFC 5246, August 2008.
+
+   [11]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [12]  Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
+         Extending the NSIS Protocol Family", RFC 5978, October 2010.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 118]
+
+RFC 5971                          GIST                      October 2010
+
+
+11.2.  Informative References
+
+   [13]  Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
+
+   [14]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
+         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
+         Specification", RFC 2205, September 1997.
+
+   [15]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+         RFC 2246, January 1999.
+
+   [16]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [17]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
+         RFC 2711, October 1999.
+
+   [18]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
+         Operation Over IP Tunnels", RFC 2746, January 2000.
+
+   [19]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
+         IPv4 Clouds", RFC 3056, February 2001.
+
+   [20]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+         RFC 3068, June 2001.
+
+   [21]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
+         "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
+         September 2001.
+
+   [22]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
+         G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
+         RFC 3209, December 2001.
+
+   [23]  Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
+         Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
+         Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-
+         Based LSP Setup using LDP", RFC 3212, January 2002.
+
+   [24]  Grossman, D., "New Terminology and Clarifications for
+         Diffserv", RFC 3260, April 2002.
+
+   [25]  Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
+         Haukka, "Security Mechanism Agreement for the Session
+         Initiation Protocol (SIP)", RFC 3329, January 2003.
+
+   [26]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
+         Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 119]
+
+RFC 5971                          GIST                      October 2010
+
+
+   [27]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+         Relays around NAT (TURN): Relay Extensions to Session Traversal
+         Utilities for NAT (STUN)", RFC 5766, April 2010.
+
+   [28]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC
+         5652, September 2009.
+
+   [29]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
+         Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
+         June 2005.
+
+   [30]  Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
+         Steps in Signaling (NSIS)", RFC 4081, June 2005.
+
+   [31]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [32]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
+         Transport Layer Security (TLS)", RFC 4279, December 2005.
+
+   [33]  Conta, A., Deering, S., and M. Gupta, "Internet Control Message
+         Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
+         Specification", RFC 4443, March 2006.
+
+   [34]  Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/
+         Firewall NSIS Signaling Layer Protocol (NSLP)", Work
+         in Progress, April 2010.
+
+   [35]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
+         IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [36]  Kent, S. and K. Seo, "Security Architecture for the Internet
+         Protocol", RFC 4301, December 2005.
+
+   [37]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
+         Nordmark, "Mobile IP Version 6 Route Optimization Security
+         Design Background", RFC 4225, December 2005.
+
+   [38]  Audet, F. and C. Jennings, "Network Address Translation (NAT)
+         Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
+         January 2007.
+
+   [39]  Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
+         September 2007.
+
+   [40]  Aoun, C. and E. Davies, "Reasons to Move the Network Address
+         Translator - Protocol Translator (NAT-PT) to Historic Status",
+         RFC 4966, July 2007.
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 120]
+
+RFC 5971                          GIST                      October 2010
+
+
+   [41]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro,
+         "The Generalized TTL Security Mechanism (GTSM)", RFC 5082,
+         October 2007.
+
+   [42]  Floyd, S. and V. Jacobson, "The Synchronisation of Periodic
+         Routing Messages", SIGCOMM Symposium on Communications
+         Architectures and Protocols pp. 33--44, September 1993.
+
+   [43]  Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal",
+         Work in Progress, July 2007.
+
+   [44]  Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", Work
+         in Progress, July 2007.
+
+   [45]  Tsenov, T., Tschofenig, H., Fu, X., Aoun, C., and E. Davies,
+         "GIST State Machine", Work in Progress, April 2010.
+
+   [46]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
+         Robustness to Blind In-Window Attacks", Work in Progress,
+         May 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 121]
+
+RFC 5971                          GIST                      October 2010
+
+
+Appendix A.  Bit-Level Formats and Error Messages
+
+   This appendix provides formats for the various component parts of the
+   GIST messages defined abstractly in Section 5.2.  The whole of this
+   appendix is normative.
+
+   Each GIST message consists of a header and a sequence of objects.
+   The GIST header has a specific format, described in more detail in
+   Appendix A.1 below.  An NSLP message is one object within a GIST
+   message.  Note that GIST itself provides the NSLP message length
+   information and signalling application identification.  General
+   object formatting guidelines are provided in Appendix A.2 below,
+   followed in Appendix A.3 by the format for each object.  Finally,
+   Appendix A.4 provides the formats used for error reporting.
+
+   In the following object diagrams, '//' is used to indicate a
+   variable-sized field and ':' is used to indicate a field that is
+   optionally present.  Any part of the object used for padding or
+   defined as reserved (marked 'Reserved' or 'Rsv' or, in the case of
+   individual bits, 'r' in the diagrams below) MUST be set to 0 on
+   transmission and MUST be ignored on reception.
+
+   The objects are encoded using big endian (network byte order).
+
+A.1.  The GIST Common Header
+
+   This header begins all GIST messages.  It has a fixed format, as
+   shown below.
+
+    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    |   GIST hops   |        Message Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           NSLPID              |C|   Type      |S|R|E| Reserved|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Version (8 bits):  The GIST protocol version number.  This
+      specification defines version number 1.
+
+   GIST hops (8 bits):  A hop count for the number of GIST-aware nodes
+      this message can still be processed by (including the
+      destination).
+
+   Message Length (16 bits):  The total number of 32-bit words in the
+      message after the common header itself.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 122]
+
+RFC 5971                          GIST                      October 2010
+
+
+   NSLPID (16 bits):  IANA-assigned identifier of the signalling
+      application to which the message refers.
+
+   C-flag:  C=1 if the message has to be able to be interpreted in the
+      absence of routing state (Section 5.2.1).
+
+   Type (7 bits):  The GIST message type (Query, Response, etc.).
+
+   S-flag:  S=1 if the IP source address is the same as the signalling
+      source address, S=0 if it is different.
+
+   R-flag:  R=1 if a reply to this message is explicitly requested.
+
+   E-flag:  E=1 if the message was explicitly routed (Section 7.1.5).
+
+   The rules governing the use of the R-flag depend on the GIST message
+   type.  It MUST always be set (R=1) in Query messages, since these
+   always elicit a Response, and never in Confirm, Data, or Error
+   messages.  It MAY be set in an MA-Hello; if set, another MA-Hello
+   MUST be sent in reply.  It MAY be set in a Response, but MUST be set
+   if the Response contains a Responder-Cookie; if set, a Confirm MUST
+   be sent in reply.  The E-flag MUST NOT be set unless the message type
+   is a Data message.
+
+   Parsing failures may be caused by unknown Version or Type values;
+   inconsistent setting of the C-flag, R-flag, or E-flag; or a Message
+   Length inconsistent with the set of objects carried.  In all cases,
+   the receiver MUST if possible return a "Common Header Parse Error"
+   message (Appendix A.4.4.1) with the appropriate subcode, and not
+   process the message further.
+
+A.2.  General Object Format
+
+   Each object begins with a fixed header giving the object Type and
+   object Length.  This is followed by the object Value, which is a
+   whole number of 32-bit words long.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |A|B|r|r|         Type          |r|r|r|r|        Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                             Value                           //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   A/B flags:  The bits marked 'A' and 'B' are extensibility flags,
+      which are defined in Appendix A.2.1 below; the remaining bits
+      marked 'r' are reserved.
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 123]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Type (12 bits):  An IANA-assigned identifier for the type of object.
+
+   Length (12 bits):  Length has the units of 32-bit words, and measures
+      the length of Value.  If there is no Value, Length=0.  If the
+      Length is not consistent with the contents of the object, an
+      "Object Value Error" message (Appendix A.4.4.10) with subcode 0
+      "Incorrect Length" MUST be returned and the message dropped.
+
+   Value (variable):  Value is (therefore) a whole number of 32-bit
+      words.  If there is any padding required, the length and location
+      are be defined by the object-specific format information; objects
+      that contain variable-length (e.g., string) types may need to
+      include additional length subfields to do so.
+
+A.2.1.  Object Extensibility
+
+   The leading 2 bits of the TLV header are used to signal the desired
+   treatment for objects whose Type field is unknown at the receiver.
+   The following three categories of objects have been identified and
+   are described here.
+
+   AB=00 ("Mandatory"):  If the object is not understood, the entire
+      message containing it MUST be rejected with an "Object Type Error"
+      message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object").
+
+   AB=01 ("Ignore"):  If the object is not understood, it MUST be
+      deleted and the rest of the message processed as usual.
+
+   AB=10 ("Forward"):  If the object is not understood, it MUST be
+      retained unchanged in any message forwarded as a result of message
+      processing, but not stored locally.
+
+   The combination AB=11 is reserved.  If a message is received
+   containing an object with AB=11, it MUST be rejected with an "Object
+   Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid
+   Extensibility Flags").
+
+   These extensibility rules define only the processing within the GIST
+   layer.  There is no requirement on GIST implementations to support an
+   extensible service interface to signalling applications, so
+   unrecognised objects with AB=01 or AB=10 do not need to be indicated
+   to NSLPs.
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 124]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.3.  GIST TLV Objects
+
+A.3.1.  Message-Routing-Information (MRI)
+
+   Type:  Message-Routing-Information
+
+   Length:  Variable (depends on MRM)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     MRM-ID    |N|  Reserved   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   //     Method-specific addressing information (variable)       //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   MRM-ID (8 bits):  An IANA-assigned identifier for the message routing
+      method.
+
+   N-flag:  If set (N=1), this means that NATs do not need to translate
+      this MRM; if clear (N=0), it means that the method-specific
+      information contains network or transport layer information that a
+      NAT must process.
+
+   The remainder of the object contains method-specific addressing
+   information, which is described below.
+
+A.3.1.1.  Path-Coupled MRM
+
+   In the case of basic path-coupled routing, the addressing information
+   takes the following format.  The N-flag has a value of 0 for this
+   MRM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 125]
+
+RFC 5971                          GIST                      October 2010
+
+
+    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-Ver |P|T|F|S|A|B|D|Reserved |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                       Source Address                        //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                      Destination Address                    //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Source Prefix |  Dest Prefix  |   Protocol    | DS-field  |Rsv|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :       Reserved        |              Flow Label               :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                              SPI                              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :          Source Port          :       Destination Port        :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP-Ver (4 bits):  The IP version number, 4 or 6.
+
+   Source/Destination address (variable):  The source and destination
+      addresses are always present and of the same type; their length
+      depends on the value in the IP-Ver field.
+
+   Source/Dest Prefix (each 8 bits):  The length of the mask to be
+      applied to the source and destination addresses for address
+      wildcarding.  In the normal case where the MRI refers only to
+      traffic between specific host addresses, the Source/Dest Prefix
+      values would both be 32 or 128 for IPv4 and IPv6, respectively.
+
+   P-flag:  P=1 means that the Protocol field is significant.
+
+   Protocol (8 bits):  The IP protocol number.  This MUST be ignored if
+      P=0.  In the case of IPv6, the Protocol field refers to the true
+      upper layer protocol carried by the packets, i.e., excluding any
+      IP option headers.  This is therefore not necessarily the same as
+      the Next Header value from the base IPv6 header.
+
+   T-flag:  T=1 means that the Diffserv field (DS-field) is significant.
+
+   DS-field (6 bits):  The Diffserv field.  See [6] and [24].
+
+   F-flag:  F=1 means that flow label is present and is significant.  F
+      MUST NOT be set if IP-Ver is not 6.
+
+   Flow Label (20 bits):  The flow label; only present if F=1.  If F=0,
+      the entire 32-bit word containing the Flow Label is absent.
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 126]
+
+RFC 5971                          GIST                      October 2010
+
+
+   S-flag:  S=1 means that the SPI field is present and is significant.
+      The S-flag MUST be 0 if the P-flag is 0.
+
+   SPI field (32 bits):  The SPI field; see [36].  If S=0, the entire
+      32-bit word containing the SPI is absent.
+
+   A/B flags:  These can only be set if P=1.  If either is set, the port
+      fields are also present.  The A flag indicates the presence of a
+      source port, the B flag that of a destination port.  If P=0, the
+      A/B flags MUST both be zero and the word containing the port
+      numbers is absent.
+
+   Source/Destination Port (each 16 bits):  If either of A (source), B
+      (destination) is set, the word containing the port numbers is
+      included in the object.  However, the contents of each field is
+      only significant if the corresponding flag is set; otherwise, the
+      contents of the field is regarded as padding, and the MRI refers
+      to all ports (i.e., acts as a wildcard).  If the flag is set and
+      Port=0x0000, the MRI will apply to a specific port, whose value is
+      not yet known.  If neither of A or B is set, the word is absent.
+
+   D-flag:  The Direction flag has the following meaning: the value 0
+      means 'in the same direction as the flow' (i.e., downstream), and
+      the value 1 means 'in the opposite direction to the flow' (i.e.,
+      upstream).
+
+   The MRI format defines a number of constraints on the allowed
+   combinations of flags and fields in the object.  If these constraints
+   are violated, this constitutes a parse error, and an "Object Value
+   Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag-
+   Field Combination") MUST be returned.
+
+A.3.1.2.  Loose-End MRM
+
+   In the case of the loose-end MRM, the addressing information takes
+   the following format.  The N-flag has a value of 0 for this MRM.
+
+    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-Ver |D|      Reserved       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                       Source Address                        //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                      Destination Address                    //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 127]
+
+RFC 5971                          GIST                      October 2010
+
+
+   IP-Ver (4 bits):  The IP version number, 4 or 6.
+
+   Source/Destination address (variable):  The source and destination
+      addresses are always present and of the same type; their length
+      depends on the value in the IP-Ver field.
+
+   D-flag:  The Direction flag has the following meaning: the value 0
+      means 'towards the edge of the network', and the value 1 means
+      'from the edge of the network'.  Note that for Q-mode messages,
+      the only valid value is D=0 (see Section 5.8.2).
+
+A.3.2.  Session Identifier
+
+   Type:  Session-Identifier
+
+   Length:  Fixed (4 32-bit words)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +                          Session ID                           +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.3.3.  Network-Layer-Information (NLI)
+
+   Type:  Network-Layer-Information
+
+   Length:  Variable (depends on length of Peer-Identity and IP version)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   PI-Length   |    IP-TTL     |IP-Ver |        Reserved       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Routing State Validity Time                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                       Peer Identity                         //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                     Interface Address                       //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 128]
+
+RFC 5971                          GIST                      October 2010
+
+
+   PI-Length (8 bits):  The byte length of the Peer Identity field.
+
+   Peer Identity (variable):  The Peer Identity field.  Note that the
+      Peer-Identity field itself is padded to a whole number of words.
+
+   IP-TTL (8 bits):  Initial or reported IP layer TTL.
+
+   IP-Ver (4 bits):  The IP version for the Interface Address field.
+
+   Interface Address (variable):  The IP address allocated to the
+      interface, matching the IP-Ver field.
+
+   Routing State Validity Time (32 bits):  The time for which the
+      routing state for this flow can be considered correct without a
+      refresh.  Given in milliseconds.  The value 0 (zero) is reserved
+      and MUST NOT be used.
+
+A.3.4.  Stack-Proposal
+
+   Type:  Stack-Proposal
+
+   Length:  Variable (depends on number of profiles and size of each
+      profile)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Prof-Count   |     Reserved                                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                    Profile 1                                //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                                                               :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                    Profile N                                //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prof-Count (8 bits): The number of profiles listed.  MUST be > 0.
+
+   Each profile is itself a sequence of protocol layers, and the profile
+   is formatted as a list as follows:
+
+   o  The first byte is a count of the number of layers in the profile.
+      MUST be > 0.
+
+   o  This is followed by a sequence of 1-byte MA-Protocol-IDs as
+      described in Section 5.7.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 129]
+
+RFC 5971                          GIST                      October 2010
+
+
+   o  The profile is padded to a word boundary with 0, 1, 2, or 3 zero
+      bytes.  These bytes MUST be ignored at the receiver.
+
+   If there are no profiles (Prof-Count=0), then an "Object Value Error"
+   message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported")
+   MUST be returned; if a particular profile is empty (the leading byte
+   of the profile is zero), then subcode 3 ("Empty List") MUST be used.
+   In both cases, the message MUST be dropped.
+
+A.3.5.  Stack-Configuration-Data
+
+   Type:  Stack-Configuration-Data
+
+   Length:  Variable (depends on number of protocols and size of each
+      MA-protocol-options field)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   MPO-Count   |     Reserved                                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           MA-Hold-Time                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                     MA-protocol-options 1                   //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                                                               :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                     MA-protocol-options N                   //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   MPO-Count (8 bits):  The number of MA-protocol-options fields present
+      (these contain their own length information).  The MPO-Count MAY
+      be zero, but this will only be the case if none of the MA-
+      protocols referred to in the Stack-Proposal require option data.
+
+   MA-Hold-Time (32 bits):  The time for which the messaging association
+      will be held open without traffic or a hello message.  Note that
+      this value is given in milliseconds, so the default time of 30
+      seconds (Section 4.4.5) corresponds to a value of 30000.  The
+      value 0 (zero) is reserved and MUST NOT be used.
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 130]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The MA-protocol-options fields are formatted as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |MA-Protocol-ID |     Profile   |    Length     |D|  Reserved   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                         Options Data                        //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   MA-Protocol-ID (8 bits):  Protocol identifier as described in
+      Section 5.7.
+
+   Profile (8 bits):  Tag indicating which profile from the accompanying
+      Stack-Proposal object this applies to.  Profiles are numbered from
+      1 upwards; the special value 0 indicates 'applies to all
+      profiles'.
+
+   Length (8 bits):  The byte length of MA-protocol-options field that
+      follows.  This will be zero-padded up to the next word boundary.
+
+   D-flag:  If set (D=1), this protocol MUST NOT be used for a messaging
+      association.
+
+   Options Data (variable):  Any options data for this protocol.  Note
+      that the format of the options data might differ depending on
+      whether the field is in a Query or Response.
+
+A.3.6.  Query-Cookie
+
+   Type:  Query-Cookie
+
+   Length:  Variable (selected by Querying node)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                        Query-Cookie                         //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The content is defined by the implementation.  See Section 8.5 for
+   further discussion.
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 131]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.3.7.  Responder-Cookie
+
+   Type:  Responder-Cookie
+
+   Length:  Variable (selected by Responding node)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                      Responder-Cookie                       //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The content is defined by the implementation.  See Section 8.5 for
+   further discussion.
+
+A.3.8.  Hello-ID
+
+   Type:  Hello-ID
+
+   Length:  Fixed (1 32-bit word)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Hello-ID                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The content is defined by the implementation.  See Section 5.2.2 for
+   further discussion.
+
+A.3.9.  NAT-Traversal
+
+   Type:  NAT-Traversal
+
+   Length:  Variable (depends on length of contained fields)
+
+   This object is used to support the NAT traversal mechanisms described
+   in Section 7.2.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 132]
+
+RFC 5971                          GIST                      October 2010
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | MRI-Length    | Type-Count    |  NAT-Count    |  Reserved     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //            Original Message-Routing-Information             //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                 List of translated objects                  //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Length of opaque information  |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
+   //                Information replaced by NAT #1                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                                                               :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Length of opaque information  |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
+   //                Information replaced by NAT #N                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   MRI-Length (8 bits):  The length of the included MRI payload in
+      32-bit words.
+
+   Original Message-Routing-Information (variable):  The MRI data from
+      when the message was first sent, not including the object header.
+
+   Type-Count (8 bits):  The number of objects in the 'List of
+      translated objects' field.
+
+   List of translated objects (variable):  This field lists the types of
+      objects that were translated by every NAT through which the
+      message has passed.  Each element in the list is a 16-bit field
+      containing the first 16 bits of the object TLV header, including
+      the AB extensibility flags, 2 reserved bits, and 12-bit object
+      type.  The list is initialised by the first NAT on the path;
+      subsequent NATs may delete elements in the list.  Padded with 2
+      null bytes if necessary.
+
+   NAT-Count (8 bits):  The number of NATs traversed by the message, and
+      the number of opaque payloads at the end of the object.  The
+      length fields for each opaque payload are byte counts, not
+      including the 2 bytes of the length field itself.  Note that each
+      opaque information field is zero-padded to the next 32-bit word
+      boundary if necessary.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 133]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.3.10.  NSLP-Data
+
+   Type:  NSLP-Data
+
+   Length:  Variable (depends on NSLP)
+
+   This object is used to deliver data between NSLPs.  GIST regards the
+   data as a number of complete 32-bit words, as given by the length
+   field in the TLV; any padding to a word boundary must be carried out
+   within the NSLP itself.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                          NSLP Data                          //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.  Errors
+
+A.4.1.  Error Object
+
+   Type:  Error
+
+   Length:  Variable (depends on error)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Error Class  |           Error Code          | Error Subcode |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |S|M|C|D|Q|       Reserved      |  MRI Length   |  Info Count   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                         Common Header                         +
+   |                    (of original message)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                          Session ID                           :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                    Message Routing Information                :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                 Additional Information Fields                 :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                       Debugging Comment                       :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 134]
+
+RFC 5971                          GIST                      October 2010
+
+
+   The flags are:
+   S - S=1 means the Session ID object is present.
+   M - M=1 means MRI object is present.
+   C - C=1 means a debug Comment is present after header.
+   D - D=1 means the original message was received in D-mode.
+   Q - Q=1 means the original message was received Q-mode encapsulated
+       (can't be set if D=0).
+
+   A GIST Error Object contains an 8-bit error-class (see
+   Appendix A.4.3), a 16-bit error-code, an 8-bit error-subcode, and as
+   much information about the message that triggered the error as is
+   available.  This information MUST include the common header of the
+   original message and MUST also include the Session ID and MRI objects
+   if these could be decoded correctly.  These objects are included in
+   their entirety, except for their TLV Headers.  The MRI Length field
+   gives the length of the MRI object in 32-bit words.
+
+   The Info Count field contains the number of Additional Information
+   fields in the object, and the possible formats for these fields are
+   given in Appendix A.4.2.  The precise set of fields to include
+   depends on the error code/subcode.  For every error description in
+   the error catalogue Appendix A.4.4, the line "Additional Info:"
+   states what fields MUST be included; further fields beyond these MAY
+   be included by the sender, and the fields may be included in any
+   order.  The Debugging Comment is a null-terminated UTF-8 string,
+   padded if necessary to a whole number of 32-bit words with more null
+   characters.
+
+A.4.2.  Additional Information Fields (AI)
+
+   The Common Error Header may be followed by some Additional
+   Information fields.  Each Additional Information field has a simple
+   TLV format as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          AI-Type              |         AI-Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                          AI-Value                           //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The AI-Type is a 16-bit IANA-assigned value.  The AI-Length gives the
+   number of 32-bit words in AI-Value; if an AI-Value is not present,
+   AI-Length=0.  The AI-Types and AI-Lengths and AI-Value formats of the
+   currently defined Additional Information fields are shown below.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 135]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Message Length Info:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Calculated Length         |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   AI-Type: 1
+   AI-Length: 1
+   Calculated Length (16 bits): the length of the original message
+   calculated by adding up all the objects in the message.  Measured in
+   32-bit words.
+
+   MTU Info:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Link MTU            |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   AI-Type: 2
+   AI-Length: 1
+   Link MTU (16 bits): the IP MTU for a link along which a message
+                       could not be sent.  Measured in bytes.
+
+   Object Type Info:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Object Type           |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   AI-Type: 3
+   AI-Length: 1
+   Object type (16 bits): This provides information about the type
+                          of object that caused the error.
+
+   Object Value Info:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Rsv  |  Real Object Length   |            Offset             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                           Object                            //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   AI-Type: 4
+   AI-Length: variable (depends on object length)
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 136]
+
+RFC 5971                          GIST                      October 2010
+
+
+   This object carries information about a TLV object that was found
+   to be invalid in the original message.  An error message MAY contain
+   more than one Object Value Info object.
+
+   Real Object Length (12 bits):  Since the length in the original TLV
+      header may be inaccurate, this field provides the actual length of
+      the object (including the TLV header) included in the error
+      message.  Measured in 32-bit words.
+
+   Offset (16 bits):  The byte in the object at which the GIST node
+      found the error.  The first byte in the object has offset=0.
+
+   Object (variable):  The invalid TLV object (including the TLV
+      header).
+
+A.4.3.  Error Classes
+
+   The first byte of the Error Object, "Error Class", indicates the
+   severity level.  The currently defined severity levels are:
+
+   0 (Informational):  reply data that should not be thought of as
+      changing the condition of the protocol state machine.
+
+   1 (Success):  reply data that indicates that the message being
+      responded to has been processed successfully in some sense.
+
+   2 (Protocol-Error):  the message has been rejected because of a
+      protocol error (e.g., an error in message format).
+
+   3 (Transient-Failure):  the message has been rejected because of a
+      particular local node status that may be transient (i.e., it may
+      be worthwhile to retry after some delay).
+
+   4 (Permanent-Failure):  the message has been rejected because of
+      local node status that will not change without additional out-of-
+      band (e.g., management) operations.
+
+   Additional error class values are reserved.
+
+   The allocation of error classes to particular errors is not precise;
+   the above descriptions are deliberately informal.  Actual error
+   processing SHOULD take into account the specific error in question;
+   the error class may be useful supporting information (e.g., in
+   network debugging).
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 137]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.4.4.  Error Catalogue
+
+   This section lists all the possible GIST errors, including when they
+   are raised and what Additional Information fields MUST be carried in
+   the Error Object.
+
+A.4.4.1.  Common Header Parse Error
+
+   Class:              Protocol-Error
+   Code:               1
+   Additional Info:    For subcode 3 only, Message Length Info carries
+                       the calculated message length.
+
+   This message is sent if a GIST node receives a message where the
+   common header cannot be parsed correctly, or where an error in the
+   overall message format is detected.  Note that in this case the
+   original MRI and Session ID MUST NOT be included in the Error Object.
+   This error code is split into subcodes as follows:
+
+   0: Unknown Version:  The GIST version is unknown.  The (highest)
+      supported version supported by the node can be inferred from the
+      common header of the Error message itself.
+
+   1: Unknown Type:  The GIST message type is unknown.
+
+   2: Invalid R-flag:  The R-flag in the header is inconsistent with the
+      message type.
+
+   3: Incorrect Message Length:  The overall message length is not
+      consistent with the set of objects carried.
+
+   4: Invalid E-flag:  The E-flag is set in the header, but this is not
+      a Data message.
+
+   5: Invalid C-flag:  The C-flag was set on something other than a
+      Query message or Q-mode Data message, or was clear on a Query
+      message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 138]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.4.4.2.  Hop Limit Exceeded
+
+   Class:              Permanent-Failure
+   Code:               2
+   Additional Info:    None
+
+   This message is sent if a GIST node receives a message with a GIST
+   hop count of zero, or a GIST node tries to forward a message after
+   its GIST hop count has been decremented to zero on reception.  This
+   message indicates either a routing loop or too small an initial hop
+   count value.
+
+A.4.4.3.  Incorrect Encapsulation
+
+   Class:              Protocol-Error
+   Code:               3
+   Additional Info:    None
+
+   This message is sent if a GIST node receives a message that uses an
+   incorrect encapsulation method (e.g., a Query arrives over an MA, or
+   the Confirm for a handshake that sets up a messaging association
+   arrives in D-mode).
+
+A.4.4.4.  Incorrectly Delivered Message
+
+   Class:              Protocol-Error
+   Code:               4
+   Additional Info:    None
+
+   This message is sent if a GIST node receives a message over an MA
+   that is not associated with the MRI/NSLPID/SID combination in the
+   message.
+
+A.4.4.5.  No Routing State
+
+   Class:              Protocol-Error
+   Code:               5
+   Additional Info:    None
+
+   This message is sent if a node receives a message for which routing
+   state should exist, but has not yet been created and thus there is no
+   appropriate Querying-SM or Responding-SM.  This can occur on
+   receiving a Data or Confirm message at a node whose policy requires
+   routing state to exist before such messages can be accepted.  See
+   also Section 6.1 and Section 6.3.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 139]
+
+RFC 5971                          GIST                      October 2010
+
+
+A.4.4.6.  Unknown NSLPID
+
+   Class:              Permanent-Failure
+   Code:               6
+   Additional Info:    None
+
+   This message is sent if a router receives a directly addressed
+   message for an NSLP that it does not support.
+
+A.4.4.7.  Endpoint Found
+
+   Class:              Permanent-Failure
+   Code:               7
+   Additional Info:    None
+
+   This message is sent if a GIST node at a flow endpoint receives a
+   Query message for an NSLP that it does not support.
+
+A.4.4.8.  Message Too Large
+
+   Class:              Permanent-Failure
+   Code:               8
+   Additional Info:    MTU Info
+
+   This message is sent if a router receives a message that it can't
+   forward because it exceeds the IP MTU on the next or subsequent hops.
+
+A.4.4.9.  Object Type Error
+
+   Class:              Protocol-Error
+   Code:               9
+   Additional Info:    Object Type Info
+
+   This message is sent if a GIST node receives a message containing a
+   TLV object with an invalid type.  The message indicates the object
+   type at fault in the additional info field.  This error code is split
+   into subcodes as follows:
+
+   0: Duplicate Object:  This subcode is used if a GIST node receives a
+      message containing multiple instances of an object that may only
+      appear once in a message.  In the current specification, this
+      applies to all objects.
+
+   1: Unrecognised Object:  This subcode is used if a GIST node receives
+      a message containing an object that it does not support, and the
+      extensibility flags AB=00.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 140]
+
+RFC 5971                          GIST                      October 2010
+
+
+   2: Missing Object:  This subcode is used if a GIST node receives a
+      message that is missing one or more mandatory objects.  This
+      message is also sent if a Stack-Proposal is sent without a
+      matching Stack-Configuration-Data object when one was necessary,
+      or vice versa.
+
+   3: Invalid Object Type:  This subcode is used if the object type is
+      known, but it is not valid for this particular GIST message type.
+
+   4: Untranslated Object:  This subcode is used if the object type is
+      known and is mandatory to interpret, but it contains addressing
+      data that has not been translated by an intervening NAT.
+
+   5: Invalid Extensibility Flags:  This subcode is used if an object is
+      received with the extensibility flags AB=11.
+
+A.4.4.10.  Object Value Error
+
+   Class:              Protocol-Error
+   Code:               10
+   Additional Info:    1 or 2 Object Value Info fields as given below
+
+   This message is sent if a node receives a message containing an
+   object that cannot be properly parsed.  The error message contains a
+   single Object Value Info object, except for subcode 5 as stated
+   below.  This error code is split into subcodes as follows:
+
+   0: Incorrect Length:  The overall length does not match the object
+      length calculated from the object contents.
+
+   1: Value Not Supported:  The value of a field is not supported by the
+      GIST node.
+
+   2: Invalid Flag-Field Combination:  An object contains an invalid
+      combination of flags and/or fields.  At the moment, this only
+      relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future
+      there may be more.
+
+   3: Empty List:  At the moment, this only relates to Stack-Proposals.
+      The error message is sent if a stack proposal with a length > 0
+      contains only null bytes (a length of 0 is handled as "Value Not
+      Supported").
+
+   4: Invalid Cookie:  The message contains a cookie that could not be
+      verified by the node.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 141]
+
+RFC 5971                          GIST                      October 2010
+
+
+   5: Stack-Proposal - Stack-Configuration-Data Mismatch:  This subcode
+      is used if a GIST node receives a message in which the data in the
+      Stack-Proposal object is inconsistent with the information in the
+      Stack Configuration Data object.  In this case, both the Stack-
+      Proposal object and Stack-Configuration-Data object MUST be
+      included in separate Object Value Info fields in that order.
+
+A.4.4.11.  Invalid IP-Layer TTL
+
+   Class:              Permanent-Failure
+   Code:               11
+   Additional Info:    None
+
+   This error indicates that a message was received with an IP-layer TTL
+   outside an acceptable range, for example, that an upstream Query was
+   received with an IP layer TTL of less than 254 (i.e., more than one
+   IP hop from the sender).  The actual IP distance can be derived from
+   the IP-TTL information in the NLI object carried in the same message.
+
+A.4.4.12.  MRI Validation Failure
+
+   Class:              Permanent-Failure
+   Code:               12
+   Additional Info:    Object Value Info
+
+   This error indicates that a message was received with an MRI that
+   could not be accepted, e.g., because of too much wildcarding or
+   failing some validation check (cf. Section 5.8.1.2).  The Object
+   Value Info includes the MRI so the error originator can indicate the
+   part of the MRI that caused the problem.  The error code is divided
+   into subcodes as follows:
+
+   0: MRI Too Wild:  The MRI contained too much wildcarding (e.g., too
+      short a destination address prefix) to be forwarded correctly down
+      a single path.
+
+   1: IP Version Mismatch:  The MRI in a path-coupled Query message
+      refers to an IP version that is not implemented on the interface
+      used, or is different from the IP version of the Query
+      encapsulation (see Section 7.4).
+
+   2: Ingress Filter Failure:  The MRI in a path-coupled Query message
+      describes a flow that would not pass ingress filtering on the
+      interface used.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 142]
+
+RFC 5971                          GIST                      October 2010
+
+
+Appendix B.  API between GIST and Signalling Applications
+
+   This appendix provides an abstract API between GIST and signalling
+   applications.  It should not constrain implementers, but rather help
+   clarify the interface between the different layers of the NSIS
+   protocol suite.  In addition, although some of the data types carry
+   the information from GIST information elements, this does not imply
+   that the format of that data as sent over the API has to be the same.
+
+   Conceptually, the API has similarities to the sockets API,
+   particularly that for unconnected UDP sockets.  An extension for an
+   API like that for UDP connected sockets could be considered.  In this
+   case, for example, the only information needed in a SendMessage
+   primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
+   (which can be null).  Other information that was persistent for a
+   group of messages could be configured once for the socket.  Such
+   extensions may make a concrete implementation more efficient but do
+   not change the API semantics, and so are not considered further here.
+
+B.1.  SendMessage
+
+   This primitive is passed from a signalling application to GIST.  It
+   is used whenever the signalling application wants to initiate sending
+   a message.
+
+   SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
+                 NSLPID, Session-ID, MRI, SII-Handle,
+                 Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )
+
+   The following arguments are mandatory:
+
+   NSLP-Data:  The NSLP message itself.
+
+   NSLP-Data-Size:  The length of NSLP-Data.
+
+   NSLP-Message-Handle:  A handle for this message that can be used by
+      GIST as a reference in subsequent MessageStatus notifications
+      (Appendix B.3).  Notifications could be about error conditions or
+      about the security attributes that will be used for the message.
+      A NULL handle may be supplied if the NSLP is not interested in
+      such notifications.
+
+   NSLPID:  An identifier indicating which NSLP this is.
+
+   Session-ID:  The NSIS session identifier.  Note that it is assumed
+      that the signalling application provides this to GIST rather than
+      GIST providing a value itself.
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 143]
+
+RFC 5971                          GIST                      October 2010
+
+
+   MRI:  Message routing information for use by GIST in determining the
+      correct next GIST hop for this message.  The MRI implies the
+      message routing method to be used and the message direction.
+
+   The following arguments are optional:
+
+   SII-Handle:  A handle, previously supplied by GIST, to a data
+      structure that should be used to route the message explicitly to a
+      particular GIST next hop.
+
+   Transfer-Attributes:  Attributes defining how the message should be
+      handled (see Section 4.1.2).  The following attributes can be
+      considered:
+
+      Reliability:  Values 'unreliable' or 'reliable'.
+
+      Security:  This attribute allows the NSLP to specify what level of
+         security protection is requested for the message (such as
+         'integrity' or 'confidentiality') and can also be used to
+         specify what authenticated signalling source and destination
+         identities should be used to send the message.  The
+         possibilities can be learned by the signalling application from
+         prior MessageStatus or RecvMessage notifications.  If an NSLP-
+         Message-Handle is provided, GIST will inform the signalling
+         application of what values it has actually chosen for this
+         attribute via a MessageStatus callback.  This might take place
+         either synchronously (where GIST is selecting from available
+         messaging associations) or asynchronously (when a new messaging
+         association needs to be created).
+
+      Local Processing:  This attribute contains hints from the
+         signalling application about what local policy should be
+         applied to the message -- in particular, its transmission
+         priority relative to other messages, or whether GIST should
+         attempt to set up or maintain forward routing state.
+
+   Timeout:  Length of time GIST should attempt to send this message
+      before indicating an error.
+
+   IP-TTL:  The value of the IP layer TTL that should be used when
+      sending this message (may be overridden by GIST for particular
+      messages).
+
+   GIST-Hop-Count:  The value for the hop count when sending the
+      message.
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 144]
+
+RFC 5971                          GIST                      October 2010
+
+
+B.2.  RecvMessage
+
+   This primitive is passed from GIST to a signalling application.  It
+   is used whenever GIST receives a message from the network, including
+   the case of null messages (zero-length NSLP payload), typically
+   initial Query messages.  For Queries, the results of invoking this
+   primitive are used by GIST to check whether message routing state
+   should be created (see the discussion of the 'Routing-State-Check'
+   argument below).
+
+   RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI,
+                 Routing-State-Check, SII-Handle, Transfer-Attributes,
+                 IP-TTL, IP-Distance, GIST-Hop-Count,
+                 Inbound-Interface )
+
+   NSLP-Data:  The NSLP message itself (may be empty).
+
+   NSLP-Data-Size:  The length of NSLP-Data (may be zero).
+
+   NSLPID:  An identifier indicating which NSLP this message is for.
+
+   Session-ID:  The NSIS session identifier.
+
+   MRI:  Message routing information that was used by GIST in forwarding
+      this message.  Implicitly defines the message routing method that
+      was used and the direction of the message relative to the MRI.
+
+   Routing-State-Check:  This boolean is True if GIST is checking with
+      the signalling application to see if routing state should be
+      created with the peer or the message should be forwarded further
+      (see Section 4.3.2).  If True, the signalling application should
+      return the following values via the RecvMessage call:
+
+         A boolean indicating whether to set up the state.
+
+         Optionally, an NSLP-Payload to carry in the generated Response
+         or forwarded Query respectively.
+
+      This mechanism could be extended to enable the signalling
+      application to indicate to GIST whether state installation should
+      be immediate or deferred (see Section 5.3.3 and Section 6.3 for
+      further discussion).
+
+   SII-Handle:  A handle to a data structure, identifying a peer address
+      and interface.  Can be used to identify route changes and for
+      explicit routing to a particular GIST next hop.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 145]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Transfer-Attributes:  The reliability and security attributes that
+      were associated with the reception of this particular message.  As
+      well as the attributes associated with SendMessage, GIST may
+      indicate the level of verification of the addresses in the MRI.
+      Three attributes can be indicated:
+
+      *  Whether the signalling source address is one of the flow
+         endpoints (i.e., whether this is the first or last GIST hop).
+
+      *  Whether the signalling source address has been validated by a
+         return routability check.
+
+      *  Whether the message was explicitly routed (and so has not been
+         validated by GIST as delivered consistently with local routing
+         state).
+
+   IP-TTL:  The value of the IP layer TTL this message was received with
+      (if available).
+
+   IP-Distance:  The number of IP hops from the peer signalling node
+      that sent this message along the path, or 0 if this information is
+      not available.
+
+   GIST-Hop-Count:  The value of the hop count the message was received
+      with, after being decremented in the GIST receive-side processing.
+
+   Inbound-Interface:  Attributes of the interface on which the message
+      was received, such as whether it lies on the internal or external
+      side of a NAT.  These attributes have only local significance and
+      are defined by the implementation.
+
+B.3.  MessageStatus
+
+   This primitive is passed from GIST to a signalling application.  It
+   is used to notify the signalling application that a message that it
+   requested to be sent could not be dispatched, or to inform the
+   signalling application about the transfer attributes that have been
+   selected for the message (specifically, security attributes).  The
+   signalling application can respond to this message with a return code
+   to abort the sending of the message if the attributes are not
+   acceptable.
+
+  MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type )
+
+   NSLP-Message-Handle:  A handle for the message provided by the
+      signalling application in SendMessage.
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 146]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Transfer-Attributes:  The reliability and security attributes that
+      will be used to transmit this particular message.
+
+   Error-Type:  Indicates the type of error that occurred, for example,
+      'no next node found'.
+
+B.4.  NetworkNotification
+
+   This primitive is passed from GIST to a signalling application.  It
+   indicates that a network event of possible interest to the signalling
+   application occurred.
+
+   NetworkNotification ( NSLPID, MRI, Network-Notification-Type )
+
+   NSLPID:  An identifier indicating which NSLP this is message is for.
+
+   MRI:  Provides the message routing information to which the network
+      notification applies.
+
+   Network-Notification-Type:  Indicates the type of event that caused
+      the notification and associated additional data.  Five events have
+      been identified:
+
+      Last Node:  GIST has detected that this is the last NSLP-aware
+         node in the path.  See Section 4.3.4.
+
+      Routing Status Change:  GIST has installed new routing state, has
+         detected that existing routing state may no longer be valid, or
+         has re-established existing routing state.  See Section 7.1.3.
+         The new status is reported; if the status is Good, the SII-
+         Handle of the peer is also reported, as for RecvMessage.
+
+      Route Deletion:  GIST has determined that an old route is now
+         definitely invalid, e.g., that flows are definitely not using
+         it (see Section 7.1.4).  The SII-Handle of the peer is also
+         reported.
+
+      Node Authorisation Change:  The authorisation status of a peer has
+         changed, meaning that routing state is no longer valid or that
+         a signalling peer is no longer reachable; see Section 4.4.2.
+
+      Communication Failure:  Communication with the peer has failed;
+         messages may have been lost.
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 147]
+
+RFC 5971                          GIST                      October 2010
+
+
+B.5.  SetStateLifetime
+
+   This primitive is passed from a signalling application to GIST.  It
+   indicates the duration for which the signalling application would
+   like GIST to retain its routing state.  It can also give a hint that
+   the signalling application is no longer interested in the state.
+
+   SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime )
+
+   NSLPID:  Provides the NSLPID to which the routing state lifetime
+      applies.
+
+   MRI:  Provides the message routing information to which the routing
+      state lifetime applies; includes the direction (in the D-flag).
+
+   SID:  The session ID that the signalling application will be using
+      with this routing state.  Can be wildcarded.
+
+   State-Lifetime:  Indicates the lifetime for which the signalling
+      application wishes GIST to retain its routing state (may be zero,
+      indicating that the signalling application has no further interest
+      in the GIST state).
+
+B.6.  InvalidateRoutingState
+
+   This primitive is passed from a signalling application to GIST.  It
+   indicates that the signalling application has knowledge that the next
+   signalling hop known to GIST may no longer be valid, either because
+   of changes in the network routing or the processing capabilities of
+   signalling application nodes.  See Section 7.1.
+
+   InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data,
+                            NSLP-Data-Size, Urgent )
+
+   NSLPID:  The NSLP originating the message.  May be null (in which
+      case, the invalidation applies to all signalling applications).
+
+   MRI:  The flow for which routing state should be invalidated;
+      includes the direction of the change (in the D-flag).
+
+   Status:  The new status that should be assumed for the routing state,
+      one of Bad or Tentative (see Section 7.1.3).
+
+   NSLP-Data, NSLP-Data-Size:  (optional) A payload provided by the NSLP
+      to be used the next GIST handshake.  This can be used as part of a
+      conditional peering process (see Section 4.3.2).  The payload will
+      be transmitted without security protection.
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 148]
+
+RFC 5971                          GIST                      October 2010
+
+
+   Urgent:  A hint as to whether rediscovery should take place
+      immediately or only with the next signalling message.
+
+Appendix C.  Deployment Issues with Router Alert Options
+
+   The GIST peer discovery handshake (Section 4.4.1) depends on the
+   interception of Q-mode encapsulated IP packets (Section 4.3.1 and
+   Section 5.3.2) by routers.  There are two fundamental requirements on
+   the process:
+
+   1.  Packets relevant to GIST must be intercepted.
+
+   2.  Packets not relevant to GIST must be forwarded transparently.
+
+   This specification defines the GIST behaviour to ensure that both
+   requirements are met for a GIST-capable node.  However, GIST packets
+   will also encounter non-GIST nodes, for which requirement (2) still
+   applies.  If non-GIST nodes block Q-mode packets, GIST will not
+   function.  It is always possible for middleboxes to block specific
+   traffic types; by using a normal UDP encapsulation for Q-mode
+   traffic, GIST allows NATs at least to pass these messages
+   (Section 7.2.1), and firewalls can be configured with standard
+   policies.  However, where the Q-mode encapsulation uses a Router
+   Alert Option (RAO) at the IP level this can lead to additional
+   problems.  The situation is different for IPv4 and IPv6.
+
+   The IPv4 RAO is defined by [13], which defines the RAO format with a
+   2-byte value field; however, only one value (zero) is defined and
+   there is no IANA registry for further allocations.  It states that
+   unknown values should be ignored (i.e., the packets forwarded as
+   normal IP traffic); however, it has also been reported that some
+   existing implementations simply ignore the RAO value completely (i.e.
+   process any packet with an RAO as though the option value was zero).
+   Therefore, the use of non-zero RAO values cannot be relied on to make
+   GIST traffic transparent to existing implementations.  (Note that it
+   may still be valuable to be able to allocate non-zero RAO values for
+   IPv4: this makes the interception process more efficient for nodes
+   that do examine the value field, and makes no difference to nodes
+   that *incorrectly* ignore it.  Whether or not non-zero RAO values are
+   used does not change the GIST protocol operation, but needs to be
+   decided when new NSLPs are registered.)
+
+   The second stage of the analysis is therefore what happens when a
+   non-GIST node that implements RAO handling sees a Q-mode packet.  The
+   RAO specification simply states "Routers that recognize this option
+   shall examine packets carrying it more closely (check the IP Protocol
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 149]
+
+RFC 5971                          GIST                      October 2010
+
+
+   field, for example) to determine whether or not further processing is
+   necessary".  There are two possible basic behaviours for GIST
+   traffic:
+
+   1.  The "closer examination" of the packet is sufficiently
+       intelligent to realise that the node does not need to process it
+       and should forward it.  This could either be by virtue of the
+       fact that the node has not been configured to match IP-
+       Protocol=UDP for RAO packets at all or that even if UDP traffic
+       is intercepted the port numbers do not match anything locally
+       configured.
+
+   2.  The "closer examination" of the packet identifies it as UDP, and
+       delivers it to the UDP stack on the node.  In this case, it can
+       no longer be guaranteed to be processed appropriately.  Most
+       likely, it will simply be dropped or rejected with an ICMP error
+       (because there is no GIST process on the destination port to
+       which to deliver it).
+
+   Analysis of open-source operating system source code shows the first
+   type of behaviour, and this has also been seen in direct GIST
+   experiments with commercial routers, including the case when they
+   process other uses of the RAO (i.e., RSVP).  However, it has also
+   been reported that other RAO implementations will exhibit the second
+   type of behaviour.  The consequence of this would be that Q-mode
+   packets are blocked in the network and GIST could not be used.  Note
+   that although this is caused by some subtle details in the RAO
+   processing rules, the end result is the same as if the packet was
+   simply blocked for other reasons (for example, many IPv4 firewalls
+   drop packets with options by default).
+
+   The GIST specification allows two main options for circumventing
+   nodes that block Q-mode traffic in IPv4.  Whether to use these
+   options is a matter of implementation and configuration choice.
+
+   o  A GIST node can be configured to send Q-mode packets without the
+      RAO at all.  This should avoid the above problems, but should only
+      be done if it is known that nodes on the path to the receiver are
+      able to intercept such packets.  (See Section 5.3.2.1.)
+
+   o  If a GIST node can identify exactly where the packets are being
+      blocked (e.g., from ICMP messages), or can discover some point on
+      the path beyond the blockage (e.g., by use of traceroute or by
+      routing table analysis), it can send the Q-mode messages to that
+      point using IP-in-IP tunelling without any RAO.  This bypasses the
+      input side processing on the blocking node, but picks up normal
+      GIST behaviour beyond it.
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 150]
+
+RFC 5971                          GIST                      October 2010
+
+
+   If in the light of deployment experience the problem of blocked
+   Q-mode traffic turns out to be widespread and these techniques turn
+   out to be insufficient, a further possibility is to define an
+   alternative Q-mode encapsulation that does not use UDP.  This would
+   require a specification change.  Such an option would be restricted
+   to network-internal use, since operation through NATs and firewalls
+   would be much harder with it.
+
+   The situation with IPv6 is rather different, since in that case the
+   use of non-zero RAO values is well established in the specification
+   ([17]) and an IANA registry exists.  The main problem is that several
+   implementations are still immature: for example, some treat any RAO-
+   marked packet as though it was for local processing without further
+   analysis.  Since this prevents any RAO usage at all (including the
+   existing standardised ones) in such a network, it seems reasonable to
+   assume that such implementations will be fixed as part of the general
+   deployment of IPv6.
+
+Appendix D.  Example Routing State Table and Handshake
+
+   Figure 11 shows a signalling scenario for a single flow being managed
+   by two signalling applications using the path-coupled message routing
+   method.  The flow sender and receiver and one router support both;
+   two other routers support one each.  The figure also shows the
+   routing state table at node B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 151]
+
+RFC 5971                          GIST                      October 2010
+
+
+       A                        B          C          D           E
+   +------+                  +-----+    +-----+    +-----+    +--------+
+   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
+   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
+   |      |    +-+    +-+    |GIST |    |GIST |    |GIST |    |        |
+   +------+                  +-----+    +-----+    +-----+    +--------+
+             Flow Direction ------------------------------>>
+
+   +------------------------------------+---------+--------+-----------+
+   |     Message Routing Information    | Session | NSLPID |  Routing  |
+   |                                    |    ID   |        |   State   |
+   +------------------------------------+---------+--------+-----------+
+   |    MRM = Path-Coupled; Flow ID =   |  0xABCD |  NSLP1 |    IP-A   |
+   |   {IP-A, IP-E, proto/ports}; D=up  |         |        |           |
+   |                                    |         |        |           |
+   |    MRM = Path-Coupled; Flow ID =   |  0xABCD |  NSLP1 |   (null)  |
+   |  {IP-A, IP-E, proto/ports}; D=down |         |        |           |
+   |                                    |         |        |           |
+   |    MRM = Path-Coupled; Flow ID =   |  0x1234 |  NSLP2 |    IP-A   |
+   |   {IP-A, IP-E, proto/ports}; D=up  |         |        |           |
+   |                                    |         |        |           |
+   |    MRM = Path-Coupled; Flow ID =   |  0x1234 |  NSLP2 | Points to |
+   |  {IP-A, IP-E, proto/ports}; D=down |         |        |   B-D MA  |
+   +------------------------------------+---------+--------+-----------+
+
+                     Figure 11: A Signalling Scenario
+
+   The upstream state is just the same address for each application.
+   For the downstream direction, NSLP1 only requires D-mode messages and
+   so no explicit routing state towards C is needed.  NSLP2 requires a
+   messaging association for its messages towards node D, and node C
+   does not process NSLP2 at all, so the peer state for NSLP2 is a
+   pointer to a messaging association that runs directly from B to D.
+   Note that E is not visible in the state table (except implicitly in
+   the address in the message routing information); routing state is
+   stored only for adjacent peers.  (In addition to the peer
+   identification, IP hop counts are stored for each peer where the
+   state itself if not null; this is not shown in the table.)
+
+   Figure 12 shows a GIST handshake setting up a messaging association
+   for B-D signalling, with the exchange of Stack Proposals and MA-
+   protocol-options in each direction.  The Querying node selects TLS/
+   TCP as the stack configuration and sets up the messaging association
+   over which it sends the Confirm.
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 152]
+
+RFC 5971                          GIST                      October 2010
+
+
+    -------------------------- Query ---------------------------->
+    IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
+    D-mode magic number (0x4e04 bda5)
+    GIST(Header(Type=Query; NSLPID=NSLP2; C=1; R=1; S=0)
+         MRI(MRM=Path-Coupled; Flow=F; Direction=down)
+         SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
+         QueryCookie(0x139471239471923526)
+         StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP)
+         StackConfigurationData(HoldTime=300; #MPO=2;
+           TCP(Applicable: all; Data: null)
+           SCTP(Applicable: all; Data: null)))
+
+    <---------------------- Response ----------------------------
+    IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789)
+    D-mode magic number (0x4e04 bda5)
+    GIST(Header(Type=Response; NSLPID=NSLP2; C=0; R=1; S=1)
+         MRI(MRM=Path-Coupled; Flow=F; Direction=up)
+         SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D)
+         QueryCookie(0x139471239471923526)
+         ResponderCookie(0xacdefedcdfaeeeded)
+         StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
+         StackConfigurationData(HoldTime=200; #MPO=3;
+           TCP(Applicable: 3; Data: port=6123)
+           TCP(Applicable: 1; Data: port=5438)
+           SCTP(Applicable: all; Data: port=3333)))
+
+    -------------------------TCP SYN----------------------->
+    <----------------------TCP SYN/ACK----------------------
+    -------------------------TCP ACK----------------------->
+    TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123)
+    <-----------------------TLS INIT----------------------->
+
+    ------------------------ Confirm ---------------------------->
+    [Sent within messaging association]
+    GIST(Header(Type=Confirm; NSLPID=NSLP2; C=0; R=0; S=1)
+         MRI(MRM=Path-Coupled; Flow=F; Direction=down)
+         SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
+         ResponderCookie(0xacdefedcdfaeeeded)
+         StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
+         StackConfigurationData(HoldTime=300))
+
+                Figure 12: GIST Handshake Message Sequence
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 153]
+
+RFC 5971                          GIST                      October 2010
+
+
+Authors' Addresses
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   US
+
+   Phone: +1 212 939 7042
+   EMail: hgs+nsis@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+   Robert Hancock
+   Roke Manor Research
+   Old Salisbury Lane
+   Romsey, Hampshire  SO51 0ZN
+   UK
+
+   EMail: robert.hancock@roke.co.uk
+   URI:   http://www.roke.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Hancock         Experimental                    [Page 154]
+