Share via

3.1.5 Processing Events and Sequencing Rules

  • Article

When the existing peer receives a valid PATH_TEST message, it MUST search all its outstanding [MC-DPL8CS] and corresponding [MC-DPL8R] instructed peer connections (described in [MC-DPL8CS] section 3.1.5.2) for one that has a matching ullKey value as described in section 3.1.3. If found, and the connect attempt has not yet received any packets from the intended target IPv4 address and port, the connection target SHOULD be modified to be the source IPv4 address and port of the PATH_TEST message.

If no connect attempt is associated with a matching ullKey value, or a matching connect attempt already has received one or more packets, the existing peer MUST ignore the PATH_TEST message.

If the message is not properly formed as described in section 2.2.2, the existing peer MUST ignore the PATH_TEST message.

New peer's PATH_TEST during connect attempt from existing peer

Figure 1: New peer's PATH_TEST during connect attempt from existing peer

PATH_TEST messages are used to create mappings in NAT and firewall devices so that inbound connect attempts appear to be solicited responses to a previous outbound request through the steps identified in this section. This process assumes that the host has sent the list of existing peers to the new peer, and that the host instructs the existing peer to connect to the new peer as described in [MC-DPL8CS].

  1. The existing peer initiates a reliable protocol connection with a CONNECT message as described in [MC-DPL8R] section 2. This can be dropped by the public interface of the NAT or firewall device based on its particular filtering or port assignment policy.

  2. Simultaneously, the Retry Timer of the new peer can elapse and cause transmission of a PATH_TEST message as described in section 3.1.6. The NAT or firewall device can implicitly create a mapping between the private address of the new peer and the public address it uses to forward the message to the existing peer.

  3. The existing peer can receive the PATH_TEST message and alter the destination IPv4 address and/or port for future CONNECT message retries, if the NAT device assigned a different port number from that which had originally been tried.

  4. Because of the NAT or firewall mapping, the retried CONNECT messages can now be properly forwarded to the new peer, and the new peer can proceed with the [MC-DPL8R] CONNECTED response and the rest of the standard connection process.

If the new peer or host receives a PATH_TEST message, it MUST be silently ignored.