SixXS::Sunset 2017-06-06

FAQ : SixXS : What is sixxsd?

Other FAQ sections

  • FAQ Item
    • Features
    • Configuration
    • Special ICMPv6 replies from sixxsd
    • sixxsd IPv6 address for ICMPv6 replies
    • Extension Header Handling

What is sixxsd?

"sixxsd" is the SixXS Daemon, it is the software that runs on the PoPs and that handles the server-side of proto-41, heartbeat and AYIYA tunnels. In effect it is SixXS's own routing platform as the complete process of en/decapsulation of tunneled packets and passing it to the proper location is handled by it.

sixxsd also takes care of the latency tests and traffic statistic collection. Various statistics can be seen, when logged in, in real-time from the user home under tunnel details, eg the current location of an endpoint of a tunnel.


A short summary of features of sixxsd:

  • Handles the full IPv6 Routing process
  • En/Decapsulation of protocol-41 (6in4) and AYIYA (IPv4 in IPv6-UDP and IPv6 in IPv4-UDP)
  • Very high performance (during tests forwarded 4 Gbit/s of mixed AYIYA/proto-41 traffic)
  • Heartbeat support
  • Latency testing of active endpoints
  • Per-tunnel remote debugging option showing per-packet decisions being made
  • Per-tunnel statistics and error information
  • Per-tunnel default routed /64 towards tunnel endpoint


Except for receiving configuration instructions from our central database, and that that actually presents the statistics through the website, it effectively runs completely on it's own. Configuration instructions are pushed to the PoPs every 10 minutes.

Special ICMPv6 replies from sixxsd

sixxsd has a few 'special' ICMP replies that it replies with when a tunnel is unreachable. This allows one to easily differentiate between a tunnel that is not configured, one that is disabled or one that is not sending active heartbeats (AYIYA and heartbeat tunnels only).


This along of course with all the neccesary things like ICMPv6 Packet Too Big to indicate packets that are too large to be routed to the next hop etc.

sixxsd IPv6 address for ICMPv6 replies

When a response can be associated with a tunnel, the gateway address for that tunnel is used, this makes debugging clear as it indicates the tunnel it is related to.

When a response cannot be associated to a tunnel sixxsd uses <tunnelprefix>ffff::1 as it's source address. This address has a forward and reverse in DNS as; For example for the sixxsd's DNS label is with IPv6 address 2001:610:600:ffff::1. As sixxsd does not implement TCP/UDP etc that IP always responds with ICMPv6 unreachables even though it responds from that address.

Extension Header Handling

sixxsd inspects IP packets while forwarding for strange inconsistencies or situations which are not permitted, eg Routing Header 0.

To properly check these, we only process known extension headers and ignore those we do not know. Which might mean that an unknown extension header inserted in the chain causes the rest of the packet not be parsed.

For instance a sequence of IPv6 -> HOPOPTS -> UNKNOWN -> PROTO4 will cause sixxsd not to accept the packet as a protocol 4 (IPv4 in something else) packet. Note that forwarding of such packets is not affected though.

The official IANA Protocol Numbers list shows which protocol numbers are marked as extension headers.

Protocol Name Accepted RFC Note
0 HOPOPTS Y RFC2460 Jumbo Options are verified and handled
43 ROUTING Y RFC2460 Packets with RH0 are rejected
44 FRAGMENT N RFC2460 Fragments are not further processed
50 ESP N RFC4303 Encrypted thus useless to sixxsd
51 AH Y RFC4302
139 HIP Y RFC5201
140 SHIM6 Y RFC5533
253 TEST N RFC3692 Unknown, hence not processed
254 TEST N RFC3692 Unknown, hence not processed
Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker