PAA client

Figure: The flow of the IPv4 PAA-client.
\includegraphics[width=5.5in]{gfx/paa-client.eps}

When an unconfigured node starts the PAA service, it is started in client mode. A flow diagram describing the IPv4 PAA-client operation is illustrated in figure 12.9. The first thing the IPv4 client does, is to generate a random link-local address. It will then configure an ``alias'' interface with this address. Such alias interfaces is the way one can configure an interface with multiple IPv4 addresses on GNU/Linux systems. If PAA is set to run on eth0, the alias interface will be eth0:0. This interface will be used by both the PAA-client and later the PAA-server. Due to the binding of sockets to devices as explained in section 6.2.3, olsrd cannot run on alias interfaces. Therefore the PAA-client/server uses an alias interface leaving the ``real'' interface to olsrd. The IPv6 client uses the link-local address automatically assigned to the interface PAA uses. IPv6 allows for several IP addresses to be set for the same interface, so there is no need to set up an alias interface.

The PAA-client must periodically broadcast or multicast a Forward Request message link-local to let already configured neighbors know that they should forward all received PAA control messages link-local. In the implementation this message generation is done in a thread of its own emitting a Forward Request every 2 seconds.

The client must generate an identifier that it will use to identify itself in PAA traffic since link-local address conflicts might occur. In the implementation, this ID is the lower 32-bits of the MAC address of the interface on which PAA runs. This diminishes the uniqueness of the ID, but the chance of two WLAN interfaces using the same last 32-bits in their MAC addresses is relatively small. The first six bytes of the MAC address are the ``Organizational Unique Identifier'', while the lower six bytes are the actual factory serial number. One can however still risk an ID crash if two interfaces by different makes that share the last 4 bytes in their Organizational ID, with the same serial number were to meet. But in general, there is a much smaller chance for this happening than the upper 32-bits matching, which in many cases only would require having two interfaces bought from the same stock.

To receive a free IP address, an Address Request message is broadcasted or multicasted link-local. A node signs this request with its ID. Any neighbor that is already a configured member of the MANET routing domain and out of quarantine time, as explained later, will answer with an offered address if an address could be allocated. If no replies are received, the PAA-client can optionally configure its interface with a random address within a pre-defined address space and start the routing daemon, thus starting its own MANET.

Upon receiving the first Address Response carrying the correct ID, the requester will generate an Address Test message and broadcast or multicast it link-local to all neighbors. Any other Address Response message received for the same request is silently discarded. Any configured node that receives the Address Test message, sends an Address Test Response confirmation message so that the PAA-client can be sure that the test-message is flooded. If no Address Test Response is received by the PAA-client, a new Address Test is sent. This is repeated until at least one Address Test Response is received.

The PAA-client then waits for a given interval to receive a possibly conflicting Address Test message sent by other nodes. If this interval times out without any conflicting Address Test messages received, another Address Test message is broadcasted or multicasted. If another time interval passes without the node receiving any conflicting Address Test messages the address is considered valid and DAD is considered complete. If a conflicting message is received, the configuration process is restarted.

When a unique IP is allocated the PAA-client will configure the interface to use with the address and Forward Request messages will no longer be sent. The thread generating these is terminated. When the interface is configured, olsrd is started. The PAA-client must take care to ensure that the routing daemon will run on the correct interface. PAA is also responsible for terminating the routing-protocol process when it is terminated itself. When the routing-daemon is started, the PAA-client will put itself in server mode.

Andreas 2004-07-29