For the complete picture, as was pointed out, you should use the final RFC, not drafts. There are two relevant RFC here:
RFC 7539 describes the stream cipher ChaCha20, the MAC algorithm Poly1305, and an Authenticated Encryption with Associated Data mode that combines ChaCha20 and Poly1305 in a safe way (in particular, it uses ChaCha20 to provide the secret values needed by Poly1305).
RFC 7905 describes TLS cipher suites that rely on the AEAD construction described in RFC 7539; that RFC explains how the associated data and nonce are built in the context of TLS.
In RFC 7539, section 2.6, there are some explanations about the nonce. The nonce must have length exactly 96 bits (12 bytes); however, the following text appears:
The protocol will specify a 96-bit or 64-bit nonce. This MUST be
unique per invocation with the same key, so it MUST NOT be
randomly generated. A counter is a good way to implement this,
but other methods, such as a Linear Feedback Shift Register (LFSR)
are also acceptable. ChaCha20 as specified here requires a 96-bit
nonce. So if the provided nonce is only 64-bit, then the first 32
bits of the nonce will be set to a constant number. This will
usually be zero, but for protocols with multiple senders it may be
different for each sender, but should be the same for all
invocations of the function with the same key by a particular
This is why the test vector in RFC 7539, section 2.8.2, shows this:
000 40 41 42 43 44 45 46 47 @ABCDEFG
32-bit fixed-common part:
000 07 00 00 00
These are a 64-bit IV and a 32-bit "fixed-common part", which are meant to be assembled (concatenated) into the 96-bit value that the algorithm requires.
However, if you look at RFC 7905, you will see that what happens in TLS is something a bit different:
AEAD_CHACHA20_POLY1305 requires a 96-bit nonce, which is formed as
1. The 64-bit record sequence number is serialized as an 8-byte,
big-endian value and padded on the left with four 0x00 bytes.
2. The padded sequence number is XORed with the client_write_IV
(when the client is sending) or server_write_IV (when the server
In other words, a full 96-bit (12 bytes) value is generated from the handshake, and the record sequence number is XORed into the last 8 bytes. An alternative design, more in line with the method explained in RFC 7539, would have been to concatenate a 32-bit (4 bytes) value generated during the handshake with the 64-bit (8 bytes) record counter. However, the RFC 7905 designers found it fit to use the XOR method, which can be argued to make nonce reuse between distinct TLS connections even less probable (not that it would matter much, since distinct TLS connections also use distinct encryption keys).