Ropsten clients such as Geth and Parity use EIP 155 Simple replay attack protection to protect against Ropsten transactions being replayed on mainnet.
Excerpt (EIP 155 has an actual example):
v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing
the hash of a transaction for purposes of signing or recovering,
instead of hashing only the first six elements (ie. nonce, gasprice,
startgas, to, value, data), hash nine elements, with v replaced by
CHAIN_ID, r = 0 and s = 0. The currently existing signature scheme
using v = 27 and v = 28 remains valid and continues to operate under
the same rules as it does now.
CHAIN_ID for Ropsten is 3.
A Ropsten transaction must be crafted to the rules of EIP 155 to get replay protection. If a wallet implements EIP 155, it can issue unlimited transactions which are protected from replay attacks. If a wallet does not implement EIP 155, transactions it creates can be replayed on other networks (because they are still valid transactions and is what is meant by the last sentence in the above excerpt).
Briefly, for implementing EIP 155 in Ropsten, hash 9 elements (instead of 6) and use 41 or 42 for
nonce in Geth's Ropsten genesis file is not related to replay protection: see
What does each genesis.json parameter mean? As noted here, Parity has a separate genesis file for Ropsten and Parity would call that (pre-EIP155 replay-protection nonce) the