At the network abstraction level

First, the source Personal Node needs to send packets to the destination Foreign Node such that they go through the selected Gateway Node. To do this, the source Node cannot just put the address of the destination node as the destination address of the packet. The intra-PN routing mechanism should not need to bother with every Foreign Node address as they may overload the intra-PN routing tables. Further, if two Gateway Nodes have a path to the same Foreign Node, it is not guaranteed that the packets will go through the selected Gateway Node all the time. The routing protocol may decide to switch Gateway Node at any time without prior warning. Finally, the address space may overlap and two different Foreign Nodes may use the same address. This can happen if the Foreign Nodes use RFC1918 addresses [192], addresses with link local scope [73], or if some nodes want to sabotage the PN operation by deliberately choosing non-unique addresses. This leaves three options for the Personal Node to make sure that the packets go through the selected Gateway Node:

Tunneling An IP-in-IP tunnel is established between the Personal Node and the selected Gateway Node. The endpoints of this tunnel are intra- PN addresses while the packets in the tunnel use the Foreign Node address as the destination. To send packets in the other direction, from the Gateway node to the Personal Node, no special functionality is necessary.

Source routing The intra-PN address of the Gateway Node is used as the destination address and the final destination, the address of the Foreign Node, is placed in an option field of the IP header (e.g., using a Type 0 routing header in IPv6 [48]). In principle, this scheme and the tunneling scheme are the same. However, source routing creates slightly less overhead.

Figure 8.3: Foreign communication with a PN-unaware node

Address aliases We cannot use the addresses of the Foreign Nodes as men- tioned above, but we can inject address aliases into the intra-PN routing protocol. If each Foreign Node and Gateway Node pair has a unique address alias within the PN, then a Personal Node can select both the Foreign Node and the Gateway Node to be used and hence, the control remains with the source Node. To minimize the burden on the intra-PN routing protocol, only aliases of (Foreign Node, Gateway Node) pairs that are in use should be injected.

While the Personal Node connects to the Gateway Node, the Gateway Node also needs to setup a path through the external network to the For- eign Node and install a state for the address translation so that intra-PN addresses can be translated to the addresses used outside. When all this is in place, traffic can start to flow. The Personal Node sends the packets to the selected Gateway Node, which will remove all PN-specific headers, encryp- tions, etc. Network addresses are then translated before being forwarded to the Foreign Node. To the applications, it will look like there is an end-to-end IP connection between the two end Nodes. Figure 8.3 shows an example of communication between a Node in a PN and a PN-unaware Foreign Node through a Gateway Node according to this scheme.

The address translation can be done with standard network address port translation (NAPT) technology, usually known as just network address trans- lation (NAT) [209]. NATs are usually used to extend the limited address space in IPv4, but can also be used to hide internal address spaces used on private networks, such as PNs. The address space within a PN is to be used within the PN and is not globally unique. Because of this, network addresses must be translated and mapped when packets flow in and out of a PN and this is typical tasks of NATs. Hence, standard NAT technology will work.

8.4. BRIDGING INSIDE AND OUTSIDE PROTOCOLS 181

Figure 8.4: Foreign communication with a PN-unaware node

The next requirement regards accepting incoming connections from For- eign Nodes; it is actually not very different from the outgoing connections. First, the Gateway Nodes must somehow make sure that the PN is known to the outside world, for instance by advertising itself in the local vicinity. However, no PN-internal addresses should be advertised outside the PN be- cause of privacy reasons and the fact that PN-internal addresses may only be unique within the PN. Instead, the Gateway Nodes advertise their own ex- ternal addresses used within the external networks plus the Services that the Cluster or PN can offer. Then, as requests to establish communication arrive at the Gateway Nodes, they need to determine whether to accept the con- nection or not. If the connection is approved, an appropriate Personal Node is chosen to become the end Node. Higher layer information may determine this, based on what type of connection or what Service is requested.

From here on, there is no difference between this case and the case when a Personal Node initiated the connection. An address translation state needs to be installed in the Gateway Node that translates the network addresses. When packets arrive at the Gateway Node, it adds the necessary headers and encryption before the packets enter the PN and are forwarded to their final destinations. All the rest remains the same, except that the foreign PN will select the Gateway Node in this case.

The case when two PNs want to communicate with each other is nothing more than the combination of the two scenarios mentioned above: Figure 8.4 illustrates this.