A number of issues (at least 2, 3, 5, 8, 16, 18, 19) have interactions with the
low (close to IP layer) aspects of GIMPS message formatting. In order to prepare
for solutions to these issues, the following changes to the specification are
proposed; some are conceptual clarifications about the structure of the
protocol, and some are detailed changes of message or object layout.

1. The IP/transport layer encapsulation for a GIMPS message is assumed to have
no semantic significance for the signalling. The sender chooses the
encapsulation to provide the best likelihood that the message will be seen by
the correct peer (e.g. that it will follow the same path as the data); the
receiver can examine the encapsulation to derive information about the network
layer topology relevant to the signalling path, e.g. how many IP hops are
involved, or the IP address of the peer, or the presence of a NAT in the path.

2. Message Routing Methods must refer to a directed path in the network; the
Message Routing Information must implicitly include a source and destination
address and a direction relative to the path.

3. The D mode encapsulation will be derived from the MRI, but some
implementation freedom is needed (e.g. for source address selection). To allow
the receiver to analyse the encapsulation, the GIMPS header will include flags
to say how the IP header was constructed.

4. The role of a GIMPS D mode message will no longer be dependent on the
direction it is being sent in. Instead, the GIMPS header will include a message
type.

5. The routing state for a given MRI/NSLPID (for each direction) will be allowed
to include a measure of the distance to adjacent signalling peers (essentially,
IP hop count). This distance will therefore be measured and signalled by the
GIMPS Q/R/C exchange; it will be measured by messages in the 'forwards'
direction (relative to the MRI) and reported by messages in the reverse
direction. This information will be carried in the Node Addressing Object.