As part of a broader organisational restructure, data networking research at Swinburne University of Technology has moved from the Centre for Advanced Internet Architecture (CAIA) to the Internet For Things (I4T) Research Lab.

Although CAIA no longer exists, this website reflects CAIA's activities and outputs between March 2002 and February 2017, and is being maintained as a service to the broader data networking research community.

SONATA - SCTP Over NAT Adaptation


Some initial considerations on supporting SCTP with NAT have been proposed by Xie (IETF Internet Draft), however this project will look to extend on this work and provide a working implementation. A NAT implementation to support SCTP based on the typical TCP and/or UDP NAT implementation has a number of problems:

  • The SCTP Checksum is calculated over the entire SCTP packet, not just just the transport layer header. Any modification of the port numbers used would require the checksum to be recalculated for the entire packet. Such an implementation would be inefficient where NAT is typically deployed on low-powered home-user routers
  • The SCTP Protocol is multi-homed, even if only one address is available behind the NAT, the other end of the association may have multiple end-points. In this situation port numbers must be preserved for the whole association
  • There can be multiple associations sharing the same address/port-number end-points. For example, two PCs behind the NAT may choose the same local port number to associate with a remote end-point. In this case we must be able to differentiate between the two associations on the outside of the NAT

Association Identification

We propose to build an implementation that uses the unique Verification Tag (VTag) field of the SCTP header to identify unique associations. Under this scenario it would not be necessary to change the port numbers of any SCTP association as it traverses the NAT. The major benefit is that the SCTP checksum would not need to be recalculated for every packet traversing the NAT.

The SCTP VTag uniquely identifies an association and should be randomly generated for each association. In a correct implementation, it is unlikely that that a VTag will be duplicated for concurrent flows to different endpoints of two distinct associations. The lookup table for NAT translations should base its decisions on the VTags of SCTP packets traversing the NAT, modifying the IP layer header while leaving the SCTP layer information intact.

Implementation Description

The NAT implementation must be able to handle an SCTP association being initiated from either side of the NAT (ie. initiated from inside or outside the NAT). An association initiated from outside the NAT will only succeed if the specified port has been configured to be forwarded to a endpoint inside the NAT.

Within the INIT chunk of the first SCTP packet of an association is the Initiation Tag. The INIT responder must use this value to populate the VTag for every SCTP packet sent as part of that association. The SCTP INIT packet must be parsed to extract this value and store it in the NAT table.

The response to the INIT is an INIT-ACK, the specified VTag must match the Initiation Tag stored from the prior INIT. Within the INIT-ACK is a second Initiation Tag which is used by the sender of the initial INIT to populate the VTag field for every SCTP packet sent as part of that association. The INIT-ACK packet must be parsed to extract this value and store it in the NAT table.

At this point VTags, end-point IP addresses and port number pairs for the association are known. This approach also works for SCTP associations initiated from outside the NAT as long as an appropriate port forwarding rule is configured. Note that port forwarding can only be to an internal IP address and not to a different port number as this would require recalculating the checksum for each SCTP packet. If an INIT is received where no port forwarding rule exists, the NAT responds as if the port was not opened. INIT Packet information:

  • The initiator IP Address and Port Number
  • The responder IP Address and Port Number
  • The responder VTag (from the Initiation Tag)

When the reply INIT-ACK is received, the receiver Port Number and VTag are checked. The Packet is forwarded only if there is a match in the NAT table. Information gained from the INIT-ACK packet includes:

  • The initiator VTag (from the Initiation Tag)
  • Now the NAT table entry is populated

Any future inbound packets with the appropriate external VTag (from any IP Address) are NATed through to the mapped internal IP Address. Any outbound packets with the appropriate internal VTag (regardless of the destination IP Address) are also NATed. This allows the multi-homing feature to work.

Address Management

An SCTP association may have multiple end-points, the NAT should parse INIT and INIT-ACK packets to extract advertised IP addresses and - if necessary - perform NAT, update the packets and recalculate the checksum. A proposed extension whereby address end-points can be dynamically added or removed (see here) may need to be treated similarly.

Other Cases

The NAT table must be properly maintained, particularly in the case of an association terminating. Similarly, SCTP packets where no association exists within the NAT table should result in the association being terminated via the use of an SCTP ABORT packet.

Last Updated: Friday 28-Nov-2008 15:54:38 AEDT | Maintained by: Jason But ( | Authorised by: Grenville Armitage (