FAQ : SixXS : What is sixxsd?
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:
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 sixxsd.city-sequencenumber;.tld.sixxs.net. For example for nlams05.sixxs.net the sixxsd's DNS label is sixxsd.ams-05.nl.sixxs.net 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
The official IANA Protocol Numbers list shows which protocol numbers are marked as extension headers.