Section 11 describes the use of the Channel mechanism. Section 4 plus the specific rules mentioned here. The message is first checked for validity. The Send indication MUST contain both an XOR-PEER-ADDRESS attribute and a DATA attribute. If one of these attributes is missing or invalid, then the message is discarded. Note that the DATA attribute is allowed to contain zero bytes of data.
The Send indication may also contain the DONT-FRAGMENT attribute. If the server is unable to set the DF bit on outgoing UDP datagrams when this attribute is present, then the server acts as if the DONT- FRAGMENT attribute is an unknown comprehension-required attribute (and thus the Send indication is discarded). The server also checks that there is a permission installed for the IP address contained in the XOR-PEER-ADDRESS attribute. If no such permission exists, the message is discarded. Note that a Send indication never causes the server to refresh the permission. The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server silently discards the Send indication. If everything is OK, then the server forms a UDP datagram as follows: o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the Send indication arrived; o the destination transport address is taken from the XOR-PEER- ADDRESS attribute; o the data following the UDP header is the contents of the value field of the DATA attribute. The handling of the DONT-FRAGMENT attribute (if present), is described in Section 12. The resulting UDP datagram is then sent to the peer. Section 8. If relaying is permitted, then the server checks if there is a channel bound to the peer that sent the UDP datagram (see Section 11). If a channel is bound, then processing proceeds as described in Section 11.7. If relaying is permitted but no channel is bound to the peer, then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA
attribute is set to the value of the 'data octets' field from the datagram, and the XOR-PEER-ADDRESS attribute is set to the source transport address of the received UDP datagram. The Data indication is then sent on the 5-tuple associated with the allocation. Section 11.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows: 0x0000 through 0x3FFF: These values can never be used for channel numbers. 0x4000 through 0x7FFF: These values are the allowed channel numbers (16,383 possible values). 0x8000 through 0xFFFF: These values are reserved for future use. Because of this division, ChannelData messages can be distinguished from STUN-formatted messages (e.g., Allocate request, Send indication, etc.) by examining the first two bits of the message: 0b00: STUN-formatted message (since the first two bits of a STUN- formatted message are always zero).
0b01: ChannelData message (since the channel number is the first field in the ChannelData message and channel numbers fall in the range 0x4000 - 0x7FFF). 0b10: Reserved 0b11: Reserved The reserved values may be used in the future to extend the range of channel numbers. Thus, an implementation MUST NOT assume that a TURN message always starts with a 0 bit. Channel bindings are always initiated by the client. The client can bind a channel to a peer at any time during the lifetime of the allocation. The client may bind a channel to a peer before exchanging data with it, or after exchanging data with it (using Send and Data indications) for some time, or may choose never to bind a channel to it. The client can also bind channels to some peers while not binding channels to other peers. Channel bindings are specific to an allocation, so that the use of a channel number or peer transport address in a channel binding in one allocation has no impact on their use in a different allocation. If an allocation expires, all its channel bindings expire with it. A channel binding consists of: o a channel number; o a transport address (of the peer); and o A time-to-expiry timer. Within the context of an allocation, a channel binding is uniquely identified either by the channel number or by the peer's transport address. Thus, the same channel cannot be bound to two different transport addresses, nor can the same transport address be bound to two different channels. A channel binding lasts for 10 minutes unless refreshed. Refreshing the binding (by the server receiving a ChannelBind request rebinding the channel to the same peer) resets the time-to-expiry timer back to 10 minutes. When the channel binding expires, the channel becomes unbound. Once unbound, the channel number can be bound to a different transport address, and the transport address can be bound to a different channel number. To prevent race conditions, the client MUST wait 5
minutes after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number. When binding a channel to a peer, the client SHOULD be prepared to receive ChannelData messages on the channel from the server as soon as it has sent the ChannelBind request. Over UDP, it is possible for the client to receive ChannelData messages from the server before it receives a ChannelBind success response. In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data or use Send indications until the channel binding is confirmed. Section 8). To initiate the ChannelBind transaction, the client forms a ChannelBind request. The channel to be bound is specified in a CHANNEL-NUMBER attribute, and the peer's transport address is specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes the restrictions on these attributes. Rebinding a channel to the same transport address that it is already bound to provides a way to refresh a channel binding and the corresponding permission without sending data to the peer. Note however, that permissions need to be refreshed more frequently than channels. Section 4 plus the specific rules mentioned here. The server checks the following: o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute;
o The channel number is in the range 0x4000 through 0x7FFE (inclusive); o The channel number is not currently bound to a different transport address (same transport address is OK); o The transport address is not currently bound to a different channel number. If any of these tests fail, the server replies with a 400 (Bad Request) error. The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error. If the request is valid, but the server is unable to fulfill the request due to some capacity limit or similar, the server replies with a 508 (Insufficient Capacity) error. Otherwise, the server replies with a ChannelBind success response. There are no required attributes in a successful ChannelBind response. If the server can satisfy the request, then the server creates or refreshes the channel binding using the channel number in the CHANNEL-NUMBER attribute and the transport address in the XOR-PEER- ADDRESS attribute. The server also installs or refreshes a permission for the IP address in the XOR-PEER-ADDRESS attribute as described in Section 8. NOTE: A server need not do anything special to implement idempotency of ChannelBind requests over UDP using the "stateless stack approach". Retransmitted ChannelBind requests will simply refresh the channel binding and the corresponding permission. Furthermore, the client must wait 5 minutes before binding a previously bound channel number or peer address to a different channel, eliminating the possibility that the transaction would initially fail but succeed on a retransmission.
If the client receives a ChannelBind failure response that indicates that the channel information is out-of-sync between the client and the server (e.g., an unexpected 400 "Bad Request" response), then it is RECOMMENDED that the client immediately delete the allocation and start afresh with a new allocation. Section 11.4.
Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4. Over UDP, the padding is not required but MAY be included. The ChannelData message is then sent on the 5-tuple associated with the allocation. Section 11.5. If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded. On the client, it is RECOMMENDED that the client discard the ChannelData message if the client believes there is no active permission towards the peer. On the server, the receipt of a ChannelData message MUST NOT refresh either the channel binding or the permission towards the peer. On the server, if no errors are detected, the server relays the application data to the peer by forming a UDP datagram as follows: o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived; o the destination transport address is the transport address to which the channel is bound;
o the data following the UDP header is the contents of the data field of the ChannelData message. The resulting UDP datagram is then sent to the peer. Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent. Section 10.3. If that section indicates that a ChannelData message should be sent (because there is a channel bound to the peer that sent to the UDP datagram), then the server forms and sends a ChannelData message as described in Section 11.5. RFC2474] Preferred Behavior: Set the outgoing value to the incoming value, unless the server includes a differentiated services classifier and marker [RFC2474].
Alternate Behavior: Set the outgoing value to a fixed value, which by default is Best Effort unless configured otherwise. In both cases, if the server is immediately adjacent to a differentiated services classifier and marker, then DSCP MAY be set to any arbitrary value in the direction towards the classifier. Explicit Congestion Notification (ECN) field [RFC3168] Preferred Behavior: Set the outgoing value to the incoming value, UNLESS the server is doing Active Queue Management, the incoming ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server wishes to indicate that congestion has been experienced, in which case set the outgoing value to CE (=0b11). Alternate Behavior: Set the outgoing value to Not-ECT (=0b00). IPv4 Fragmentation fields Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the DF bit in the outgoing IP header to 1. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), copy the DF bit from the DF bit of the incoming packet that contained the application data. Set the other fragmentation fields (Identification, More Fragments, Fragment Offset) as appropriate for a packet originating from the server. Alternate Behavior: As described in the Preferred Behavior, except always assume the incoming DF bit is 0. In both the Preferred and Alternate Behaviors, the resulting packet may be too large for the outgoing link. If this is the case, then the normal fragmentation rules apply [RFC1122]. IPv4 Options Preferred Behavior: The outgoing packet is sent without any IPv4 options. Alternate Behavior: Same as preferred.
0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R| RFFU | +-+-+-+-+-+-+-+-+ The value contains a single 1-bit flag: R: If 1, the server is requested to reserve the next-higher port number (on the same IP address) for a subsequent allocation. If 0, no such reservation is requested. The other 7 bits of the attribute's value must be set to zero on transmission and ignored on reception. Since the length of this attribute is not a multiple of 4, padding must immediately follow this attribute. Protocol-Numbers]. This specification only allows the use of codepoint 17 (User Datagram Protocol). The RFFU field MUST be set to zero on transmission and MUST be ignored on reception. It is reserved for future uses.