Date: Wed, 20 May 2015 19:07:43 GMT From: roam@FreeBSD.org To: svn-soc-all@FreeBSD.org Subject: socsvn commit: r285758 - soc2015/roam Message-ID: <201505201907.t4KJ7hfH094671@socsvn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: roam Date: Wed May 20 19:07:42 2015 New Revision: 285758 URL: http://svnweb.FreeBSD.org/socsvn/?view=rev&rev=285758 Log: Add a simple project description for ng_ayiya. Added: soc2015/roam/ soc2015/roam/README.txt Added: soc2015/roam/README.txt ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ soc2015/roam/README.txt Wed May 20 19:07:42 2015 (r285758) @@ -0,0 +1,44 @@ +ng_ayiya - a SixXS IPv6 tunnel broker AYIYA Netgraph node +========================================================= + +Student: Peter Pentchev (roam@) +Mentor: Bjoern A. Zeeb (bz+soc@) + +Project description +------------------- + +Implement a netgraph node that connects to a netgraph kernel socket node and +a netgraph interface node and understands enough of the AYIYA protocol to +pass packets back and forth. Use a control connection to user space to +handle all other signalling. Adjust the sixxs-aiccu implementation and add +the netgraph implementation as an option for the FreeBSD port. + +The goal of this project is to create a Netgraph node that acts as a link +between a socket (TCP, UDP, SCTP, ...) connection to an AYIYA server +(for a start, the SixXS POPs) and a local network interface (for a start, +one that can route IPv6 traffic). The operation of the node should be +controlled via a Netgraph socket (the usual way of letting a kernel Netgraph +node communicate with a userland program) by higher-level tunnel negotiation +software like SixXS's AICCU. The scope of the project also includes +the necessary changes to SixXS's AICCU software to use the Netgraph +framework instead of tunneling the packets by itself, as it does in its +standard mode of operation. + +The initial design of the Netgraph node is as follows: +- a "ayiya" hook to a ng_ksocket node for the "uplink" connection to the + AYIYA POP of the tunnel broker +- an "inet6" hook to a ng_iface node +- a "control" hook to a ng_socket node for configuration from userland +- a "secrethash" control message to set the pre-hashed shared secret for + the AYIYA protocol, so that the node need not know the actual secret +- possibly more control messages to set the node's mode of operation in + additional ways (possibly reconnect to the AYIYA POP by itself, etc.) +- possibly two-way data communication with the userland utility through + the control hook for e.g. responding to AYIYA queries, passing on + the POP's message of the day, etc. + +The hook names should either be the exact strings "ayiya", "control" and +"secret" or strings that start with those tags followed by a slash ("/") and +additional data that the node will ignore. This allows the administrator or +the userland utility to keep more information for clarity, documentation and +so on, without interfering with the operation of the node.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201505201907.t4KJ7hfH094671>