Section 5.3.2 fully restructured including more detailed rules for IP-level    
    interception and UDP encapsulation, including a description of what IP-layer
options are allowed (and how they should be handled) and what additional
encapsulation layers are not allowed. Note that this text also covers certain
changes needed for router alert issues.

Revised 5.3.2 text:

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 encapsulation is similar to
   normal encapsulation, with changes in IP address selection, IP
   options, a defined method for selecting UDP ports, and a magic number
   at the start of the UDP payload.

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 with 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 ([3] 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 by default.
   However, a node MAY make the initial interception decision based
   purely on IP-Protocol number transport header analysis (see below).
   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 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 which do not properly support RAO; further details are
   discussed in Appendix C.

   It is possible that fragmented datagrams including an RAO will not be
   correctly handled in the network, so the sender MAY set the Don't
   Fragment (DF) bit in the IPv4 header in order to detect that a
   message has encountered a link with an abnormally low MTU.  If the
   sender sets DF for any reason, it SHOULD use the signalling source
   address for the IP source address in order to receive the ICMP error.

   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 the hop-by-hop option header, the IP
   header MUST NOT include any extension headers other than routing
   options or destination options, 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 which 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
   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.

   Within the network, there may be packets using the GIST UDP port but
   which are not in fact GIST traffic.  To avoid misidentification of
   such packets, the UDP payload in Q-mode messages MUST always begin
   with a 32 bit magic number which is followed immediately by the
   normal GIST common header; the value of the magic number is 0x4e04
   bda5 in network byte order.

   Packets which do not match both the UDP destination port and the
   magic number MUST be forwarded transparently at the IP layer,
   regardless of any RAO value they contain.  Regardless of the IP level
   encapsulation, if either the destination port is not the GIST port,
   or the payload start does not match the magic number, the packet MUST
   NOT be identified as a GIST Q-mode packet and MUST be processed as a
   normal IP datagram.

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 options semantics are
   independent of the payload: UDP payload modifications are not
   prevented by the options and do not affect the options content, and
   conversely the presence of the options does not affect the UDP
   payload.

   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 on SHOULD be processed identically as
   they would be for a normally forwarded IP packet.

Note also the context for the comment (Sam again):

GIST raises significant architectural concerns about the end-to-end service
model of the Internet.  In particular there are multiple cases having to do with
q-mode encapsulation where GIST nodes consume, generate and modify packets that
are neither sourced nor destined for them.  The advice in section 7.2 goes
against the requirements of section 7 of draft-ietf-behave-nat-udp (an approved
BCP).  Even so, I think it is necessary for GIST to do these things but I think
we need to be very careful about the interactions with other things deployed on
the Internet.  We also want to discourage general applications of this form and
I think it critical that we establish architectural requirements so that future
proposals work with GIST.  I don't think it necessary to block GIST on that
architectural work.  RFC 4080 discusses some but not all of these issues; as
best I can tell it does not discuss AH, interactions with other IP options and
hop-by hop/destination options, etc.  Also, RFC 4080 is not an IETF consensus
document; it was a working group document that was never submitted for IETF last
call.  This is not just an NSIS issue; it is an IP service model issue.

From Sam Hartman: we need to ...

Discuss interactions with AH and other mechanisms that might be added
(especially by intermediate routers) that could cause problems when packets are
modified.