The main addition is a new section 7.2.1 which describes the detection of legacy
NATs and the response to that detection. The text of 7.2.1 is as follows:

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-
   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, and if these addresses do not match this indicates that a
   legacy NAT has been found.  For MRMs which 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/
   response 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 which 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.

There are additional small changes in section 1.1 to move some of the general
text on the NAT problem to section 7.2, and in sections 5.2.2, 5.3.1 and 5.3.2
to pin down the requirements on how the S flag must be set in D mode messages,
and when the S flag causes addresses in IP headers and the NLI to be checked.

The current specification does not describe what happens when GIST messages hit
a legacy (GIST-unaware) NAT. The minimal requirement is to detect the NAT and
fail gracefully; however, the processing rules that make this happen need to be
described.