diff --git a/doc/plan.org b/doc/plan.org
index d65ec1e..e60c6a9 100644
--- a/doc/plan.org
+++ b/doc/plan.org
@@ -3,6 +3,75 @@
 | 2019-02-22 | have all papers handed in |
 | 2019-08-21 | hand in                   |
 * Topics / Tasks
-** TODO Create task description to be handed in mystudies
-** TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area
-**
+** Admin
+*** TODO Create task description to be handed in mystudies
+*** TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area
+*** TODO Create list of tasks / initial brainstorming
+*** TODO Find out how-when-whom-where to meet / define schedule
+*** TODO Latex and/or org-mode for the thesis?
+** Thesis implementation
+*** TODO Get feature list of jool
+*** TODO Get feature list of tayga
+*** TODO Setup P4 base
+*** DONE Setup test VM: 2a0a:e5c0:2:12:400:f0ff:fea9:c3e3
+** Thesis documentation
+* Proposal / task description
+** Task description for mystudies
+*** High speed NAT64 with P4
+Currently there are two main open source NAT64 solution available:
+tayga and jool. The former is a single threaded, cpu bound user
+space solution, the latter a custom Linux kernel module.
+
+This thesis challenges this status quo by developing a P4 based
+solution supporting all features of jool/tayga and comparing the
+performance, security and adaptivity of the solutions.
+** Original ideas
+Proposal 1: Automating NAT64 with P4
+
+In IPv6 only data centers IPv4 connectivity is still a business
+requirement. Current state of the art methods include layer 7 proxying
+or static assignments. both featuring static assignments.
+
+A flexible, dynamic assignment of IPv4 addresses to IPv6 hosts, similar
+to lease times in DHCPv4 and prefix delegations in DHCPv6 could reduce
+the pressure on IPv4 addresses.
+
+I would suggest the develop of a new protocol (likely UDP embedded) that
+allows hosts to request on-network support for IPv4 addresses. As IPv4
+addresses have to be treated as "expensive", an accounting metric has to
+be introduced. While in the business world this is usually related to
+money, in the network world IPv4 users could be paying the network by
+(reduced) bandwidth.
+
+If such a metric existed, devices attached to the network could also try
+to negotiate and wait for using IPv4, when the price / penality for IPv4
+is low (this might be very suitable for mail exchangers for instance).
+
+
+Proposal 2: High speed NAT64 with P4
+
+Currently there are two main open source NAT64 solution available:
+tayga[0] and jool[1]. The former is a single threaded, cpu bound user
+space solution, the latter a custom Linux kernel module.
+
+I would like to challenge this status quo and develop a P4 based
+solution supporting all features of jool/tayga and comparing the
+performance and adaptivity of the solutions.
+
+[0] http://www.litech.org/tayga/
+[1] https://www.jool.mx/en/index.html
+
+
+Proposal 3: Challenging the status quo with IPv10
+
+The de facto standard in networking is to treat IPv4
+and IPv6 as "impossible to combine". This proposal is
+to challenge this notion with three different methods:
+
+- Extensions to IPv4 to request remote IPv6 transport
+- Extensions to IPv6 to request remote IPv4 transport
+- Support in network equipment to handle the extensions
+
+As the IPv4 header does not allow embedding IPv6 addresses due to size
+limitations, embedding the destination address in a secondary header
+might be necessary (possibly encapsulated in UDP).