Class FragmentHandler

java.lang.Object
net.i2p.router.tunnel.FragmentHandler
Direct Known Subclasses:
RouterFragmentHandler

class FragmentHandler
extends Object
Handle fragments at the endpoint of a tunnel, peeling off fully completed I2NPMessages when they arrive, and dropping fragments if they take too long to arrive. From tunnel-alt.html:

When the gateway wants to deliver data through the tunnel, it first gathers zero or more I2NP messages, selects how much padding will be used, fragments it across the necessary number of 1KB tunnel messages, and decides how each I2NP message should be handled by the tunnel endpoint, encoding that data into the raw tunnel payload:

  • The 4 byte Tunnel ID
  • The 16 byte IV
  • the first 4 bytes of the SHA256 of (the remaining preprocessed data concatenated with the IV), using the IV as will be seen on the tunnel endpoint (for outbound tunnels), or the IV as was seen on the tunnel gateway (for inbound tunnels) (see below for IV processing).
  • 0 or more bytes containing random nonzero integers
  • 1 byte containing 0x00
  • a series of zero or more { instructions, message } pairs

Note that the padding, if any, must be before the instruction/message pairs. there is no provision for padding at the end.

The instructions are encoded with a single control byte, followed by any necessary additional information. The first bit in that control byte determines how the remainder of the header is interpreted - if it is not set, the message is either not fragmented or this is the first fragment in the message. If it is set, this is a follow on fragment.

With the first (leftmost or MSB) bit being 0, the instructions are:

  • 1 byte control byte:
          bit 0: is follow on fragment?  (1 = true, 0 = false, must be 0)
       bits 1-2: delivery type
                 (0x0 = LOCAL, 0x01 = TUNNEL, 0x02 = ROUTER)
          bit 3: delay included?  (1 = true, 0 = false) (unimplemented)
          bit 4: fragmented?  (1 = true, 0 = false)
          bit 5: extended options?  (1 = true, 0 = false) (unimplemented)
       bits 6-7: reserved
  • if the delivery type was TUNNEL, a 4 byte tunnel ID
  • if the delivery type was TUNNEL or ROUTER, a 32 byte router hash
  • if the delay included flag is true, a 1 byte value (unimplemented):
          bit 0: type (0 = strict, 1 = randomized)
       bits 1-7: delay exponent (2^value minutes)
  • if the fragmented flag is true, a 4 byte message ID
  • if the extended options flag is true (unimplemented):
       = a 1 byte option size (in bytes)
       = that many bytes
  • 2 byte size of the I2NP message or this fragment

If the first bit being 1, the instructions are:

  • 1 byte control byte:
          bit 0: is follow on fragment?  (1 = true, 0 = false, must be 1)
       bits 1-6: fragment number
          bit 7: is last? (1 = true, 0 = false)
  • 4 byte message ID (same one defined in the first fragment)
  • 2 byte size of this fragment

The I2NP message is encoded in its standard form, and the preprocessed payload must be padded to a multiple of 16 bytes. The total size, including the tunnel ID and IV, is 1028 bytes.