Gateway              Relay-1
                  -------              -------
                     :                    :
  Query      Expired |                    |
  Timer (QT)-------->|                    |
                     |  Relay Discovery   |
                     |------------------->|
                     |                    |
                     | Relay Advertisement|
                     |<-------------------|
                     |                    |
                     |      Request       |
                     |------------------->|
                     |                    |
                     |  Membership Query  |
                     |<===================|
               Start |                    |
        (QT)<--------| Membership Update  |
                     |===================>|
                     |                    |
                     ~                    ~             Relay-2
             Expired |                    |             -------
        (QT)-------->|                    |                :
                     |  Relay Discovery   |                |
                     |------------------------------------>|
                     |                    |                |
                     | Relay Advertisement|                |
                     |<------------------------------------|
                     |                    |                |
                     |     Teardown       |                |
                     |------------------->|                |
                     |                    |                |
                     |      Request       |                |
                     |------------------------------------>|
                     |                    |                |
                     |  Membership Query  |                |
                     |<====================================|
               Start |                    |                |
        (QT)<--------| Membership Update  |                |
                     |====================================>|
                     |                    |                |
                     :                    :                :

Figure 18: Teardown After Relay Address Change

5.2.3.4.5. Discovery Nonce Generation

The discovery nonce MUST be a random, non-zero, 32-bit value, and if possible, SHOULD be computed using a cryptographically secure pseudo random number generator. A new nonce SHOULD be generated each time the gateway restarts the relay discovery process. The same nonce SHOULD be used when retransmitting a Relay Discovery message.

5.2.3.5. Membership Query Procedure

This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.

5.2.3.5.1. Starting the Membership Update Cycle

A gateway may send a Request message to start a membership update cycle (following the optional relay discovery procedure) in response to the following events:

• When the gateway pseudo-interface is activated.
• When the gateway wishes to report a group subscription when none currently exist.

Starting the membership update cycle when a gateway pseudo-interface is started provides several benefits:

• Better performance by allowing state-change reports to be sent as they are generated, thus minimizing the time to join.
• More robustness by relying on unsolicited state-change reports to update group membership state rather than the current-state reports generated by the membership update cycle. Unsolicited state-change reports are typically retransmitted multiple times while current-state reports are not.
• Simplified implementation by eliminating any need to queue IGMP/MLD messages for delivery after a Membership Query is received, since the IGMP/MLD state-change messages may be sent as they are generated.

However, this approach places an additional load on relays as a gateway will send periodic requests even when it has no multicast subscriptions. To reduce load on a relay, a gateway SHOULD only send a Membership Update message while it has active group subscriptions. A relay will still need to compute a Response MAC for each Request, but will not be required to recompute it a second time to authenticate a Membership Update message that contains no subscriptions.

5.2.3.5.2. Sending a Request Message

A gateway sends a Request message to a relay to solicit a Membership Query response and start the membership update cycle.

A gateway constructs a Request message containing a Request Nonce value computed as described in Section 5.2.3.5.6. The gateway MUST set the "P" flag in the Request message to identify the protocol the gateway wishes the relay to use for the general query response.

A gateway MUST send a Request message using the current Relay Address and IANA-assigned AMT port number as the destination.

A gateway MUST save a copy of the Request message or save the Request Nonce and P-flag values for possible retransmission and verification of a Membership Query response.

When a gateway sends a Request message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.

5.2.3.5.3. Waiting for a Membership Query Message

A gateway MAY retransmit a Request message if it does not receive a matching Membership Query message within some timeout period. If the gateway retransmits the message multiple times, the timeout period SHOULD be adjusted to provide an random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).

If a gateway that uses relay discovery does not receive a Membership Query within a specified time period or after a specified number of retries, the gateway SHOULD stop waiting for a Membership Query message and restart relay discovery to locate another relay.

5.2.3.5.4. Handling a Membership Query Message

When a gateway receives a Membership Query message it must first determine whether it should accept or ignore the message. A gateway MUST ignore a Membership Query message, or the encapsulated IP datagram within it, if the message fails to satisfy any of the following requirements:

• The gateway MUST be waiting for a Membership Query message.
• The Request Nonce value contained in the Membership Query MUST equal the Request Nonce value contained in the Request message.
• The source IP address and UDP port of the Membership Query MUST equal the destination IP address and UDP port of the matching Request message (i.e., the current relay address).
• The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 message. The protocol MUST match the protocol identified by the "P" flag in the Request message.
• The IGMPv3 or MLDv2 message MUST be a general query message.
• The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Query message.

Once a gateway receives a Membership Query response to a Request message, it SHOULD ignore any other Membership Query messages that arrive on the AMT interface until it sends a new Request message.

The gateway MUST save the Membership Query message, or the Request Nonce, Response MAC, Gateway IP Address and Gateway Port Number fields for use in sending subsequent Membership Update and Teardown messages.

The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification and dispatching to the IGMP or MLD implementation running on the pseudo-interface. The gateway MUST NOT forward any octets that might exist between the encapsulated IP datagram and the end of the message or Gateway Address fields.

The MLD protocol specification indicates that senders should use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not normally share a common subnet. For this reason, a gateway implementation MUST accept MLD (and IGMP) query message datagrams regardless of the source IP address they carry. This may require additional processing on the part of the gateway that might be avoided if the relay and gateway use the IPv4 and IPv6 addresses allocated for use in AMT encapsulated control packets as described in Section 5.2.1.

The gateway MUST start a timer that will trigger the next iteration of the membership update cycle by executing the membership query procedure. The gateway SHOULD compute the timer duration from the Querier's Query Interval Code carried by the general-query. A gateway MAY use a smaller timer duration if required to refresh a NAT mapping that would otherwise timeout. A gateway MAY use a larger timer duration if it has no group subscriptions to report.

If the gateway supports the Teardown message and the G-flag is set in the Membership Query message, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed the gateway MUST send a Teardown message to the relay as described in Section 5.2.3.7.

If the L-flag is set in the Membership Query message, the relay is reporting that it is NOT accepting Membership Update messages that create new tunnel endpoints and will simply ignore any that do. If the L-flag is set and the gateway is not currently reporting any group subscriptions to the relay, the gateway SHOULD stop sending periodic Request messages and restart the relay discovery procedure (if discovery is enabled) to find a new relay with which to communicate. The gateway MAY continue to send updates even if the L-flag is set, if it has previously reported group subscriptions to the relay, one or more subscriptions still exist and the gateway endpoint address has not changed since the last Membership Query was received (see previous paragraph).

5.2.3.5.5. Handling Query Timer Expiration

When the query timer (started in the previous step) expires, the gateway should execute the membership query procedure again to continue the membership update cycle.

5.2.3.5.6. Request Nonce Generation

The request nonce MUST be a random value, and if possible, SHOULD be computed using a cryptographically secure pseudo random number generator. A new nonce MUST be generated each time the gateway starts the membership query process. The same nonce SHOULD be used when retransmitting a Request message.

5.2.3.6. Membership Update Procedure

This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.

The membership update process is primarily driven by the host-mode IGMP or MLD protocol implementation running on the gateway pseudo-interface. The IGMP and MLD protocols produce current-state reports in response to general queries generated by the pseudo-interface via AMT and produce state-change reports in response to receiver requests made using the IGMP or MLD service interface.

5.2.3.6.1. Handling an IGMP/MLD IP Datagram

The gateway pseudo-interface MUST accept the following IP datagrams from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo-interface:

• IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report or an IGMPv2 Leave Group message as described in Section 4 of [RFC3376].
• IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener Report or an MLDv1 Multicast Listener Done message as described in Section 5 of [RFC3810].

The gateway must be prepared to receive these messages any time the pseudo-interface is running. The gateway MUST ignore any datagrams not listed above.

A gateway that waits to start a membership update cycle until after it receives a datagram containing an IGMP/MLD state-change message MAY:

• Discard IGMP or MLD datagrams until it receives a Membership Query message, at which time it processes the Membership Query message as normal to eventually produce a current-state report on the pseudo-interface which describes the end state (RECOMMENDED).
• Insert IGMP or MLD datagrams into a queue for transmission after it receives a Membership Query message.

If and when a gateway receives a Membership Query message (for IGMP or MLD) it sends any queued or incoming IGMP or MLD datagrams to the relay as described in the next section.

5.2.3.6.2. Sending a Membership Update Message

A gateway cannot send a Membership Update message to a relay until it has received a Membership Query message from a relay. If the gateway has not yet located a relay with which to communicate, it MUST first execute the relay discovery procedure described in Section 5.2.3.4 to obtain a relay address. If the gateway has a relay address, but has not yet received a Membership Query message, it MUST first execute the membership query procedure described in Section 5.2.3.5 to obtain a Request Nonce and Response MAC that can be used to send a Membership Update message.

Once a gateway possesses a valid Relay Address, Request Nonce and Response MAC, it may encapsulate the IP datagram containing the IGMP/MLD message into a Membership Update message. The gateway MUST copy the Request Nonce and Response MAC values from the last Membership Query received from the relay into the corresponding fields in the Membership Update. The gateway MUST send the Membership Update message using the Relay Address and IANA-assigned AMT port number as the destination.

When a gateway sends a Membership Update message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.

5.2.3.7. Teardown Procedure

This section describes gateway requirements related to the teardown message sequence described in Section 4.2.1.3.

Gateway support for the Teardown message is RECOMMENDED.

A gateway that supports Teardown SHOULD make use of Teardown functionality if it receives a Membership Query message from a relay that has the "G" flag set to indicate that it contains valid gateway address fields.

5.2.3.7.1. Handling a Membership Query Message

As described in Section 5.2.3.5.4, if a gateway supports the Teardown message, has reported active group subscriptions, and receives a Membership Query message with the "G" flag set, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed the gateway MUST send a Teardown message as described in the next section.

5.2.3.7.2. Sending a Teardown Message

A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to the gateway and delete any group memberships created by the gateway.

When a gateway constructs a Teardown message, it MUST copy the Request Nonce, Response MAC, Gateway IP Address and Gateway Port Number fields from the Membership Query message that provided the Response MAC for the last Membership Update message sent, into the corresponding fields of the Teardown message.

A gateway MUST send the Teardown message using the Relay Address and IANA-assigned AMT port number as the destination. A gateway MAY send the Teardown message multiple times for robustness. The gateway SHOULD use the Querier's Robustness Variable (QRV) field contained in the query encapsulated within the last Membership Query to set the limit on the number of retransmissions (See Section 4.1.6 in [RFC3376] and Section 5.1.7 in [RFC3810]). If the gateway sends the Teardown message multiple times, it SHOULD insert a delay between each transmission using the timing algorithm employed in IGMP/MLD for transmitting unsolicited state-change reports. The RECOMMENDED default delay value is 1 second.

When a gateway sends a Teardown message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.

5.2.3.8. Shutdown

When a gateway pseudo-interface is stopped and the gateway has existing group subscriptions, the gateway SHOULD either:

• Send a Teardown message to the relay as described in Section 5.2.3.7, but only if the gateway supports the Teardown message, and the current relay is returning gateway address fields in Membership Query messages, or
• Send a Membership Update message to the relay that will delete existing group subscriptions.

5.2.3.9. Handling ICMP Destination Unreachable Responses

A gateway may receive an ICMP "Destination Unreachable" message [RFC0792] after sending an AMT message. Whether the gateway is notified that an ICMP message was received is highly dependent on firewall and gateway IP stack behavior and gateway implementation.

If the reception of an ICMP Destination Unreachable message is reported to the gateway while waiting to receive an AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:

1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach as it does not allow for transient network changes.
2. If the last message sent was a Relay Discovery or Request message, the gateway MAY simply ignore the ICMP response and continue waiting for incoming AMT messages. If the gateway is configured to retransmit Relay Discovery or Request messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
3. If the last message sent was a Membership Update message, the gateway MAY start a new membership update and associated Request retransmission cycle.

If the reception of an ICMP Destination Unreachable message is reported to the gateway when attempting to transmit a new AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:

1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach as it does not allow for transient network changes.
2. If the last message sent was a Relay Discovery, Request or Teardown message, the gateway MAY attempt to transmit the new message. If the gateway is configured to retransmit Relay Discovery, Request or Teardown messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
3. If the last message sent was a Membership Update message, the gateway SHOULD start a new membership update and associated Request retransmission cycle.

5.3. Relay Operation

The following sections describe relay implementation requirements. A non-normative discussion of relay operation may be found in Section 4.2.

5.3.1. IP/IGMP/MLD Protocol Requirements

A relay requires a subset of router-mode IGMP and MLD functionality to provide group membership tracking and report processing.

A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and MAY support IPv4/IGMPv3.

A relay MUST apply the forwarding rules described in Section 6.3 of [RFC3376] and Section 7.3 of [RFC3810].

A relay MUST handle incoming reports as described in Section 6.4 of [RFC3376] and Section 7.4 of [RFC3810] with the exception that actions that lead to queries MAY be modified to eliminate query generation. A relay MUST accept IGMP and MLD report datagrams regardless of the IP source address carried by those datagrams.

All other aspects of IGMP/MLD router behavior, such as the handling of queries, querier election, etc., are not used or required for relay operation.

5.3.2. Startup

If a relay is deployed for anycast discovery, the relay MUST advertise an anycast Relay Discovery Address Prefix into the unicast routing system of the anycast domain. An address within that prefix, i.e., a Relay Discovery Address, MUST be assigned to a relay interface.

A unicast IPv4 and/or IPv6 address MUST be assigned to the relay interface that will be used to send and receive AMT control and data messages. This address or addresses are returned in Relay Advertisement messages.

The remaining details of relay "startup" are highly implementation-dependent and are not addressed in this document.

5.3.3. Running

When a relay is started, it begins listening for AMT messages on the interface to which the unicast Relay Address(es) has been assigned, i.e., the address returned in Relay Advertisement messages.

5.3.3.1. Handling AMT Messages

A relay MUST ignore any message other than a Relay Discovery, Request, Membership Update or Teardown message. The handling of Relay Discovery, Request, Membership Update, and Teardown messages is addressed in the sections that follow.

Support for the Teardown message is OPTIONAL. If a relay does not support the Teardown message, it MUST also ignore this message.

A relay that conforms to this specification MUST ignore any message with a Version field value other than zero.

5.3.3.2. Handling a Relay Discovery Message

This section describes relay requirements related to the relay discovery message sequence described in Section 4.2.1.1.

A relay MUST accept and respond to Relay Discovery messages sent to an anycast relay discovery address or the unicast relay address. If a relay receives a Relay Discovery message sent to its unicast address, it MUST respond just as it would if the message had been sent to its anycast discovery address.

When a relay receives a Relay Discovery message it responds by sending a Relay Advertisement message back to the source of the Relay Discovery message. The relay MUST use the source IP address and UDP port of the Relay Discovery message as the destination IP address and UDP port. The relay MUST use the destination IP address and UDP port of the Relay Discovery as the source IP address and UDP port to ensure successful NAT traversal.

The relay MUST copy the value contained in the Discovery Nonce field of the Relay Discovery message into the Discovery Nonce field in the Relay Advertisement message.

If the Relay Discovery message was received as an IPv4 datagram, the relay MUST return an IPv4 address in the Relay Address field of the Relay Advertisement message. If the Relay Discovery message was received as an IPv6 datagram, the relay MUST return an IPv6 address in the Relay Address field.

5.3.3.3. Handling a Request Message

This section describes relay requirements related to the membership query portion of the message sequence described in Section 4.2.1.2.

When a relay receives a Request message it responds by sending a Membership Query message back to the source of the Request message.

The relay MUST use the source IP address and UDP port of the Request message as the destination IP address and UDP port for the Membership Query message. The source IP address and UDP port carried by the Membership Query MUST match the destination IP address and UDP port of the Request to ensure successful NAT traversal.

The relay MUST return the value contained in the Request Nonce field of the Request message in the Request Nonce field of the Membership Query message. The relay MUST compute a MAC value, as described in Section 5.3.5, and return that value in the Response MAC field of the Membership Query message.

If a relay supports the Teardown message, it MUST set the G-flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message it SHOULD NOT set these fields as this may cause the gateway to generate unnecessary Teardown messages.

If the P-flag in the Request message is 0, the relay MUST return an IPv4-encapsulated IGMPv3 general query in the Membership Query message. If the P-flag is 1, the relay MUST return an IPv6-encapsulated MLDv2 general query in the Membership Query message.

If the relay is not accepting Membership Update messages that create new tunnel endpoints due to resource limitations, it SHOULD set the L-flag in the Membership Query message to notify the gateway of this state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8.

The IGMPv3 general query datagram that a relay encapsulates within a Membership Query message MUST conform to the descriptions found in Section 4.1 of [RFC3376]. These datagrams MUST possess the IP headers, header options and header values called for in [RFC3376], with the following exception; the source IP address for an IGMP general query datagram MAY be set to the "unspecified" address (all octets are zero) but SHOULD be set to an address in the address range specifically assigned by IANA for use in the IGMP messages sent from a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). This exception is made because the source address that a relay might normally send may not be a valid source address on any gateway interface. The rationale for using the aforementioned source addresses is primary one of convenience - a gateway will accept an IGMP query regardless of the source address it carries. See Section 5.2.1.

The MLDv2 general query datagram that a relay encapsulates within a Membership Query message MUST conform to the descriptions found in Section 5.1 of [RFC3810]. These datagrams MUST possess the IP headers, header options and header values called for in [RFC3810], with the following exception; the source IP address for an MLD general query datagram MAY be set to the "unspecified" address (all octets are zero) but SHOULD be set to an IPv6 link-local address in the range FE80::/64. A relay may use a dynamically-generated link-local address or the fixed address FE80::2. As with IGMP, a gateway will accept an MLD query regardless of the source address it carries. See Section 5.2.1.

A relay MUST set the Querier's Query Interval Code (QQIC) field in the general query to supply the gateway with a suggested time duration to use for the membership query timer. The QQIC field is defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in [RFC3810]. A relay MAY adjust this value to affect the rate at which the Request messages are sent from a gateway. However, a gateway is allowed to use a shorter duration than specified in the QQIC field, so a relay may be limited in its ability to spread out Requests coming from a gateway.

A relay MUST set the Querier's Robustness Variable (QRV) field in the general query to a non-zero value. This value SHOULD be greater than one. If a gateway retransmits membership state change messages, it will retransmit them (robustness variable - 1) times. The QRV field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810].

A relay SHOULD set the Maximum Response Code field in the general query to a value of 1 to trigger an immediate response from the gateway (some host IGMP/MLD implementations may not accept a value of zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response Interval variable, if available, to generate the Maximum Response Code field value as the Query Response Interval variable is used in setting the duration of group state timers and must not be set to such a small value. The Maximum Response Code field is defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See Section 5.3.3.7.

5.3.3.4. Handling a Membership Update Message

This section describes relay requirements related to the membership update portion of the message sequence described in Section 4.2.1.2.

When a relay receives a Membership Update message it must first determine whether it should accept or ignore the message. A relay MUST NOT make any changes to group membership and forwarding state if the message fails to satisfy any of the following requirements:

• The IP datagram encapsulated within the message MUST be one of the following:
  • IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report message.
  • IPv4 datagram carrying an IGMPv2 Leave Group message.
  • IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener Report message.
  • IPv6 datagram carrying MLDv1 Multicast Listener Done message.
• The encapsulated IP datagram MUST satisfy the IP header requirements for the IGMP or MLD message type as described in Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of [RFC3810], and Section 3 of [RFC2710], with the following exception - a relay MUST accept an IGMP or MLD message regardless of the IP source address carried by the datagram.
• The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Update message.
• The computed checksums for the encapsulated IP datagram and its payload MUST match the values contained therein. Checksum computation and verification varies by protocol; See [RFC0791] for IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
• If processing of the encapsulated IGMP or MLD message would result in an allocation of new state or a modification of existing state, the relay MUST authenticate the source of the Membership message by verifying that the value contained in the Response MAC field equals the MAC value computed from the fields in the Membership Update message datagram. Because the private secret used to compute Response MAC values may change over time, the relay MUST retain the previous version of the private secret to use in authenticating Membership Updates sent during the subsequent query interval. If the first attempt at Response MAC authentication fails, the relay MUST attempt to authenticate the Response MAC using the previous private secret value unless 2*query_interval time has elapsed since the private secret change. See Section 5.3.5. An alternative approach to Response MAC generation that avoids repeated Response MAC computations may be found in Appendix A.1.

A relay MAY skip source authentication to reduce the computational cost of handling Membership Update messages if the relay can make a trivial determination that the IGMP/MLD message carried by the Membership Update message will produce no changes in group membership or forwarding state. The relay does not need to compute and compare MAC values if it finds there are no group subscriptions for the source of the Membership Update message and either of the following is true:

• The encapsulated IP datagram is an IGMPv3 Membership Report or MLDv2 Multicast Listener Report message that contains no group records. This may often be the case for gateways that continuously repeat the membership update cycle even though they have no group subscriptions to report.
• The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 Multicast Listener Done message.

The IGMP and MLD protocol specifications indicate that senders SHOULD use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not share a common subnet. For this reason, a relay implementation MUST accept IGMP and MLD datagrams regardless of the source IP address they carry.

Once a relay has determined that the Membership Update message is valid, it processes the encapsulated IGMP or MLD membership message to update group membership state and communicates with the multicast protocol to update forwarding state and possibly send multicast protocol messages towards upstream routers. The relay MUST ignore any octets that might exist between the encapsulated IP datagram and the end of the Membership Update message.

As described in Section 4.2.2, a relay uses the source IP address and source UDP port carried by a Membership Update messages to identify a tunnel endpoint. A relay uses the tunnel endpoint as the destination address for any Multicast Data messages it sends as a result of the group membership and forwarding state created by processing the IGMP/MLD messages contained in Membership Update messages received from the endpoint.

If a Membership Update message originates from a new endpoint, the relay MUST determine whether it can accept updates from a new endpoint. If a relay has been configured with a limit on the total number of endpoints, or a limit on the total number of endpoints for a given source address, then the relay MAY ignore the Membership Update message and possibly withdraw any Relay Discovery Address Prefix announcement that it might have made. See Section 5.3.3.8.

A relay MUST maintain some form of group membership database for each endpoint. The per-endpoint databases are used update a forwarding table containing entries that map an (*,G) or (S,G) subscription to a list of tunnel endpoints.

A relay MUST maintain some form of group membership database representing a merger of the group membership databases of all endpoints. The merged group membership database is used to update upstream multicast forwarding state.

A relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints. A relay uses this forwarding table to provide the destination address when performing UDP/IP encapsulation of the incoming multicast IP datagrams to form Multicast Data messages.

If a group filter mode for a group entry on a tunnel endpoint is EXCLUDE, the relay SHOULD NOT forward datagrams that originate from sources in the filter source list unless the relay architecture does not readily support source filtering. A relay MAY ignore the source list if necessary because gateways are expected to do their own source filtering.

5.3.3.5. Handling a Teardown Message

This section describes relay requirements related to the teardown message sequence described in Section 4.2.1.3.

When a relay (that supports the Teardown message) receives a Teardown message, it MUST first authenticate the source of the Teardown message by verifying that the Response MAC carried by the Teardown message is equal to a MAC value computed from the fields carried by the Teardown message. The method used to compute the MAC differs from that used to generate and validate the Membership Query and Membership Update messages in that the source IP address and source UDP port number used to compute the MAC are taken from the Gateway IP Address and Gateway Port Number field in the Teardown message rather than from the IP and UDP headers in the datagram that carries the Teardown message. The MAC computation is described Section 5.3.5. A relay MUST ignore a Teardown message If the computed MAC does not equal the value of the Response MAC field.

If a relay determines that a Teardown message is authentic, it MUST immediately stop transmitting Multicast Data messages to the endpoint identified by the Gateway IP Address and Gateway Port Number fields in the message. The relay MUST eventually delete any group membership and forwarding state associated with the endpoint, but MAY delay doing so to allow a gateway to recreate group membership state on a new endpoint and thereby avoid making unnecessary (temporary) changes in upstream routing/forwarding state.

The state changes made by a relay when processing a Teardown message MUST be identical to those that would be made as if the relay had received an IGMP/MLD report that would cause the IGMP or MLD protocol to delete all existing group records in the group membership database associated with the endpoint. The processing of the Teardown message should trigger or mimic the normal interaction between IGMP or MLD and a multicast protocol to produce required changes in forwarding state and possibly send prune/leave messages towards upstream routers.

5.3.3.6. Handling Multicast IP Datagrams

When a multicast IP datagram is forwarded to the relay pseudo-interface, the relay MUST, for each gateway that has expressed an interest in receiving the datagram, encapsulate the IP datagram into a Multicast Data message or messages and send that message or messages to the gateway. This process is highly implementation dependent, but conceptually requires the following steps:

• Use the IP datagram source and destination address to look up the appropriate (*,G) or (S,G) entry in the endpoint forwarding table created for the pseudo-interface as a result of IGMP/MLD processing.
• Possibly replicate the datagram for each gateway endpoint listed for that (*,G) or (S,G) entry.
• If the multicast IP datagram size exceeds the Tunnel MTU as determined according to the procedure described in Section 5.3.3.6.1, the relay must execute the procedure described in Section 5.3.3.6.2.
• Encapsulate and transmit the IP datagram according to the procedure described in Section 5.3.3.6.3.

The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface.

5.3.3.6.1. Path and Tunnel MTU

A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel that originates on the relay. A relay will use the TMTU value to determine whether an incoming multicast IP datagram can be delivered downstream in a Membership Data message without fragmentation. A relay MUST compute the TMTU by subtracting the size of the Membership Data message headers (IP, UDP, and AMT) from the current Path MTU (PMTU) associated with each AMT tunnel. The relay MUST maintain a PMTU value on a per-tunnel or per-relay basis. A relay MUST support one or both of the following methods for determining the PMTU value:See [security-considerations]). When dynamic PMTU adjustments are disabled, the PMTU for all tunnels MUST default to the Link MTU (first-hop) on the downstream interface.

• The relay MAY provide a configuration option that establishes a fixed PMTU that will be applied to all AMT tunnels originating at the relay.
• The relay MAY dynamically adjust PMTU value(s) in response to receipt of ICMP/ICMPv6 "Datagram Too Big" messages as described in [RFC1191] and [RFC1981].

If a relay supports dynamic adjustment of per-tunnel or per-relay PMTU values in response to ICMP messages, the relay MUST provide a configuration option that disables this feature and also provide a configuration option that establishes a minimum PMTU for all tunnels. These configuration options may be used to mitigate certain types of denial of service attacks (

5.3.3.6.2. MTU Filtering Procedure

This section defines procedures that a relay must execute when it receives a multicast datagram whose size is greater than the Tunnel MTU of the tunnel or tunnels through which it must be delivered.

5.3.3.6.2.1. IPv4 Multicast IP Datagrams

If the DF bit in the multicast datagram header is set to 1 (Don't Fragment), the relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv4 [RFC0792] Destination Unreachable message to the source, with type equal to 4 (fragmentation needed and DF set). The ICMP Destination Unreachable message MUST contain an next-hop MTU (as specified by [RFC1191]) and the relay MUST set the next-hop MTU to the TMTU associated with the tunnel or tunnels. If the DF bit in the multicast datagram header is set to 0 (May Fragment), the relay MUST fragment the datagram and encapsulate each fragment within Multicast Data messages for transmission through the tunnel or tunnels. This ensures that gateways will receive complete, non-fragmented Multicast Data messages, containing fragmented multicast datagram payloads. The relay SHOULD avoid generating a separate ICMP message for each tunnel, but instead send a single ICMP message with a Next-hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.

5.3.3.6.2.2. IPv6 Multicast IP Datagrams

The relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message MUST be equal to the TMTU associated with the tunnel or tunnels. The relay SHOULD avoid generating a separate ICMPv6 message for each tunnel, but instead send a single ICMPv6 message with a Next-hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.

5.3.3.6.3. Encapsulation Procedure

A relay encapsulates a multicast IP datagram in a UDP/IP Membership Data message, using the tunnel endpoint UDP/IP address as the destination address and the unicast relay address and IANA-assigned AMT port number as the source UDP/IP address. To ensure successful NAT traversal, the source address and port MUST match the destination address and port carried by the Membership Update message sent by the gateway to create the forwarding table entry.

If possible, the relay SHOULD compute a valid, non-zero checksum for the UDP datagram carrying the Multicast Data message. See Section 4.2.2.3.

The following sections describe additional requirements related to the IP protocol of the tunnel and that of the multicast IP datagram.

5.3.3.6.3.1. Tunneling over IPv4

When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in the payload header is set to 1 (Don't Fragment), the relay MUST set the DF bit in the Multicast Data IP header to 1. When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in the payload header is set to 0 (May Fragment), by default, the relay MUST set the DF bit in the Multicast Data IP header to 1. However, a relay MAY provide a configuration option that allows the DF bit to be copied from the payload header to the Multicast Data IP header to allow downstream fragmentation of the Multicast Data message. When a relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST set the DF bit in the Multicast Data IP header to 1. The relay MUST NOT transmit a Multicast Data message with an IP header in which the MF (More Fragments) bit is set to 1.

5.3.3.6.3.2. Tunneling over IPv6

When a tunneling over IPv6, a relay MUST NOT emit a Multicast Data message datagram containing an IPv6 fragment header.

5.3.3.6.4. Handling Destination Unreachable Messages

If a relay receives a sequence of ICMP or ICMPv6 messages of type "Destination Unreachable" in response to transmission of a sequence of AMT Multicast Data messages to a gateway, the relay SHOULD discontinue sending messages to that gateway and shutdown the tunnel for that gateway (Handling of ICMP "Destination Unreachable" messages with code 4, "fragmentation required" is covered in Section 5.3.3.6.1). If a relay provides this capability, it MUST provide a configuration option that indicates what number of sequential "Destination Unreachable" messages can be received and ignored before the relay will automatically shutdown a tunnel.

5.3.3.7. State Timers

A relay MUST maintain a timer or timers whose expiration will trigger the removal of any group subscriptions and forwarding state previously created for a gateway endpoint should the gateway fail to refresh the group membership state within a specified time interval.

A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810], or may maintain a per-endpoint timer to trigger the deletion of group membership state.

If a per-endpoint timer is used, the relay MUST restart this timer each time it receives a new Membership Update message from the gateway endpoint.

The endpoint timer duration MAY be computed from tunable IGMP/MLD variables as follows:

((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval

If IGMP/MLD default values are used for these variables, the gateway will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be greater than the query interval suggested in the last Membership Query message sent to the gateway endpoint.

Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the Query_Response_Interval value SHOULD be greater than or equal to 10s to allow for packet loss and round-trip time in the Request/Membership Query message exchange.

5.3.3.8. Relay Resource Management

A relay may be configured with various service limits to ensure a minimum level of performance for gateways that connect to it.

If a relay has determined that it has reached or exceeded maximum allowable capacity or has otherwise exhausted resources required to support additional gateways, it SHOULD withdraw any Relay Discovery Address Prefix it has advertised into the unicast internetwork and SHOULD set the L-flag in any Membership Query messages it returns to gateways while in this state.

If the relay receives an update from a gateway that adds group membership or forwarding state for an endpoint that has already reached maximum allowable state entries, the relay SHOULD continue to accept updates from the gateway but ignore any group membership/forwarding state additions requested by that gateway.

If the relay receives an update from a gateway that would create a new tunnel endpoint for a source IP address that has already reached the maximum allowable number of endpoints (maximum UDP ports), it should simply ignore the Membership Update.

5.3.4. Shutdown

The following steps should be treated as an abstract description of the shutdown procedure for a relay:

• Withdraw the Relay Discovery Address Prefix advertisement (if used).
• Stop listening for Relay Discovery messages.
• Stop listening for control messages from gateways.
• Stop sending data messages to gateways.
• Delete all AMT group membership and forwarding state created on the relay, coordinating with the multicast routing protocol to update the group membership state on upstream interfaces as required.

5.3.5. Response MAC Generation

A Response MAC is produced by a hash digest computation. A Response MAC computation is required in the following situations:

• To generate a Response MAC value from a Request message for inclusion in a Membership Query message.
• To generate a Response MAC value from a Membership Update message for use in authenticating the Response MAC carried within that message.
• To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message.

Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. The hash function RECOMMENDED for use in computing the Response MAC is the MD5 hash digest [RFC1321], though hash functions or keyed-hash functions of greater cryptographic strength may be used.

The digest MUST be computed over the following values:

• The Source IP address of the message (or Teardown Gateway IP Address field)
• The Source UDP port of the message (or Teardown Gateway Port Number field)
• The Request Nonce contained in the message.
• A private secret known only to the relay

An Response MAC generation solution that satisfies these requirements is described in Appendix A.1.

5.3.6. Private Secret Generation

The private secret, or hash-key, is a random value that the relay includes in the Response MAC hash digest computation. A relay SHOULD periodically compute a new private secret. The RECOMMENDED maximum interval is 2 hours. A relay MUST retain the prior secret for use in verifying MAC values that were sent to gateways just prior to the use of the new secret.

The private secret SHOULD be computed using a cryptographically-secure pseudo-random number generator. The private secret width SHOULD equal that of the hash function used to compute the Response MAC, e.g., 128-bits for an MD5 hash.

6. Security Considerations

AMT is not intended to be a strongly secured protocol. In general, the protocol provides the same level of security and robustness as is provided by the UDP, IGMP and MLD protocols on which it relies. The lack of strong security features can largely be attributed to the desire to make the protocol light-weight by minimizing the state and computation required to service a single gateway, thereby allowing a relay to service a larger number of gateways.

Many of the threats and vectors described in [RFC3552] may be employed against the protocol to launch various types of denial-of-service attacks that can affect the functioning of gateways or their ability to locate and communicate with a relay. These scenarios are described below.

As is the case for UDP, IGMP and MLD, the AMT protocol provides no mechanisms for ensuring message delivery or integrity. The protocol does not provide confidentiality - multicast groups, sources and streams requested by a gateway are sent in the clear.

The protocol does use a three-way handshake to provide trivial source authentication for state allocation and updates (see below). The protocol also requires gateways and relays to ignore malformed messages and those messages that do not carry expected address values or protocol payload types or content.

6.1. Relays

The three-way handshake provided by the membership update message sequence (See [overview-membership-update-sequence]) provides a defense against source-spoofing-based resource-exhaustion attacks on a relay by requiring source authentication before state allocation. However, attackers may still attempt to flood a relay with Request and Membership Update messages to force the relay to make the hash computations in an effort to consume computational resources. Implementations may choose to limit the frequency with which a relay responds to Request messages sent from a single IP address or IP address and UDP port pair, but support for this functionality is not required. The three-way handshake provides no defense against an eavesdropping or man-in-the-middle attacker.

Attackers that execute the gateway protocol may consume relay resources by instantiating a large number of tunnels or joining a large number of multicast streams. A relay implementation should provide a mechanism for limiting the number of tunnels (Multicast Data message destinations) that can be created for a single gateway source address. Relays should also provide a means for limiting the number of joins per tunnel instance as a defense against these attacks.

Relays may withdraw their AMT anycast prefix advertisement when they reach configured maximum capacity or exhaust required resources. This behavior allows gateways to use the relay discovery process to find the next topologically-nearest relay that has advertised the prefix. This behavior also allows a successful resource exhaustion attack to propagate from one relay to the next until all relays reachable using the anycast address have effectively been taken offline. This behavior may also be used to acquire the unicast addresses for individual relays which can then be used to launch a DDoS attack on all of the relays without using the relay discovery process. To prevent wider disruption of AMT-based distribution network, relay anycast address advertisements can be limited to specific administrative routing domains. This will isolate such attacks to a single domain.

The Path and Tunnel MTU adjustment (discovery) procedure described in Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small Path MTU. In the second attack, the forged message indicates an inordinately large Path MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, relay implementations MUST include a configuration option to disable Path MTU adjustments on AMT tunnels.

6.2. Gateways

A passive eavesdropper may launch a denial-of-service attack on a gateway by capturing a Membership Query or Membership Update message and using the request nonce and message authentication code carried by the captured message to send a spoofed a Membership Update or Teardown message to the relay. The spoofed messages may be used to modify or destroy group membership state associated with the gateway, thereby changing or interrupting the multicast traffic flows.

A passive eavesdropper may also spoof Multicast Data messages in an attempt to overload the gateway or disrupt or supplant existing traffic flows. A properly implemented gateway will filter Multicast Data messages that do not originate from the expected relay address and should filter non-multicast packets and multicast IP packets whose group or source addresses are not included in the current reception state for the gateway pseudo-interface.

An active eavesdropper may launch a man-in-the-middle attack in which messages normally exchanged between a gateway and relay are intercepted, modified, spoofed or discarded by the attacker. The attacker may deny access to, modify or replace requested multicast traffic. The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack - any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams.

The anycast discovery technique for finding relays (see Section 4.1.4) introduces a risk that a rogue router or a rogue AS could introduce a bogus route to a specific Relay Discovery Address prefix, and thus divert or absorb Relay Discovery messages sent by gateways. Network managers must guarantee the integrity of their routing to a particular Relay Discovery Address prefix in much the same way that they guarantee the integrity of all other routes.

6.3. Encapsulated IP Packets

An attacker forging or modifying a Membership Query or Membership Update message may attempt to embed something other than an IGMP or MLD message within the encapsulated IP packet carried by these messages in an effort to introduce these into the recipient's IP stack. A properly implemented gateway or relay will ignore any such messages - and may further choose to ignore Membership Query messages that do not contain a IGMP/MLD general queries or Membership Update messages that do not contain IGMP/MLD membership reports.

Properly implemented gateways and relays will also filter encapsulated IP packets that appear corrupted or truncated by verifying packet length and checksums.

7. IANA Considerations

7.1. IPv4 and IPv6 Anycast Prefix Allocation

The following unicast prefixes have been assigned to provide anycast routing of relay discovery messages to public AMT Relays as described in Section 4.1.4.

7.1.1. IPv4

IANA has assigned 154.7.0/24 for IPv4 relays.

7.1.2. IPv6

IANA has assigned 2001:0003::/32 for IPv6 relays.

7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses

IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses.

7.3. UDP Port Number

The UDP port number 2268 has been reserved with IANA for use in the implementation and deployment of AMT. The protocol described by this document continues to use this port number according to the intent of the original request. This port number should be assigned to AMT upon acceptance of this I-D.

8. Contributors

The following people provided significant contributions to the design of the protocol and earlier versions of this specification:

  Amit Aggarwal
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA  98052-6399
  USA
  Email: amitag@microsoft.com

  Thomas Morin
  Orange
  2, avenue Pierre Marzin
  Lannion  22300
  France
  Email: thomas.morin@orange.com

  Dirk Ooms
  OneSparrow
  Robert Molsstraat 11; 2018 Antwerp
  Belgium
  EMail: dirk@onesparrow.com

  Tom Pusateri
  !j
  Wake Forest, NC
  USA
  Email: pusateri@bangj.com

  Dave Thaler
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA  98052-6399
  USA
  Email: dthaler@microsoft.com
        

9. Acknowledgments

The authors would like to thank the following individuals for their suggestions, comments, and corrections:

    Mark Altom
    Toerless Eckert
    Marshall Eubanks
    Gorry Fairhurst
    Dino Farinacci
    Lenny Giuliano
    Andy Huang
    Tom Imburgia
    Patricia McCrink
    Han Nguyen
    Doug Nortz
    Pekka Savola
    Robert Sayko
    Greg Shepherd
    Steve Simlo
    Mohit Talwar
    Lorenzo Vicisano
    Kurt Windisch
    John Zwiebel

The anycast discovery mechanism described in this document is based on similar work done by the NGTrans WG for obtaining automatic IPv6 connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document.

Juniper Networks was instrumental in funding several versions of this draft as well as an open source implementation.

10. References

10.1. Normative References

10.2. Informative References

Appendix A. Implementation Notes

A.1. Response MAC Generation and Keying

This specification does not require relays to use any particular method to compute the Response MAC field value - only that it contain a hash of the source IP address, source UDP port, request nonce, and a private secret known only to the relay. This allows the relay implementor a significant amount of leeway in the computation and structure of the value stored in the Response MAC field.

Section Section 5.3.6 states that a relay should periodically compute a new private secret (or hash-key) for MAC generation. To prevent the relay from rejecting Membership Update messages that contain Response MAC values computed from an old secret, the relay is required to retain the previous secret so that it can re-attempt authentication using the old secret, should authentication fail after recomputing the MAC using the new secret. However, this approach requires a relay to do at least two hash computations for every Membership Update message that carries an old or a invalid MAC. A better approach would be to include information within the message that the relay could use to choose a single secret for authentication rather relying on sequential authentication failures to test all possible secrets.

The solution proposed here is to compute and exchange an "authentication cookie" rather than a simple hash value in the Response MAC field. The authentication cookie would combine a timestamp with a hash value. The timestamp is used to calculate the age of the cookie, allowing the relay to reject a message if the cookie's age is greater than some maximum allowable value. If the cookie has not expired, the relay uses the timestamp to lookup the secret that was in use at that time and then compute and compare the hash portion of the cookie to authenticate the message source.

A second purpose served by including the timestamp in the MAC field is that it allows the relay to contribute an unpredictable value to the authentication hash. This contribution provides a defense against attempts to use a hash reversal algorithm to determine the relay's private secret as the hash result will change over time even if the nonce carried by the Request message does not.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  V=0  |4 or 5|   Reserved   | |         Response MAC          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Request Nonce                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  V=0  |4 or 5|   Reserved   | |          Timestamp            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Request Nonce                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :

    +-------------------------+--------------/ /-----------------+
 -->| Timestamp(N1) [16-bits] |    Random Secret [128-bits]      |
|   +-------------------------+--------------/ /-----------------+
|___________________________________________________________________
                                                                    |
    +-------------------------+--------------/ /-----------------+  |
 -->| Timestamp(N1) [16-bits] |    Random Secret [128-bits]      |--
|   +-------------------------+--------------/ /-----------------+
|___________________________________________________________________
                                                                    |
    +-------------------------+--------------/ /-----------------+  |
 -->| Timestamp(N1) [16-bits] |    Random Secret [128-bits]      |--
|   +-------------------------+--------------/ /-----------------+
|
|__ Current
    Secret