## 5 Auto-Configuration Protocol  
As exposed in Section 3, our auto-configuration protocol is lightweight and provides IP addresses to the eHealth devices (via prefix delegation), as well as a default route to the gateway deployed in the vehicle. The protocol is based on DHCPv6, as illustrated in Figure 6. This protocol takes place on the MR before the cluster head attaches to it. Further details about the protocol are documented in [32].  
Figure 6 describes the extended message exchange performed by the vehicular gateway and the DHCPv6 entities in the infrastructure. In the original DHCPv6 protocol, to obtain a set of addresses and a default route, 10 messages are necessary (including neighbor discovery messages). The initial RS (router solicitation)/RA (router advertisement) offer the default route, whereas the subsequent DHCPv6 solicit/advertize/request/reply offers the set of addresses to the gateway (to advertise for the eHealth devices).  
Our proposal is based on DHCPv6 messages _only_ and provides the default route in addition to a distinct set of IPv6 addresses. As depicted in Figure 6, the total number of messages in the earlier exchange (gateway-infrastructure) is reduced from 10 to eight. Eventually, (2*RTT) configuration time is saved. The actual duration depends on the cellular link quality. In our laboratory setting, the round trip time (RTT) for an experimental IPv6 3G deployment (further details within Section 6.2) varies between 300-500 ms.  
In a solicit/request packet, a client lists the wanted options in the option request option (ORO), composed of a list of option codes. The DHCPv6 Server answers those packets with advertise/reply packets containing values for the options asked for by the client. The relay receives the message from  
Figure 6: Auto-configuration protocol messages. A comparison of the number of messages between current auto-configuration methods and the proposed one. DR stands for Default Route, P for prefix and ORO for option request option.  
the client (if the server is more than one hop away) and forwards it to the server in a relay-forward message. The server replies to the relay with an advertise/reply message encapsulated in a relay-reply message. The content of this message is extracted by the relay and sent to the client.  
In its DHCPv6 requests, the client sends a list of required options within the ORO option. This option contains three mandatory fields: OPTION_ORO, option-len and requested-option-code, followed by new option fields. The proposed option is named here OPTION_DEFAULT_ROUTER_LIST. It is possible to concatenate this value with several other existing requested-option-codes. The value of this code in this option is to be assigned. Obviously, this option needs to be understood by the server, as well.  
On the server side, the default router list option of DHCPv6 (Figure 7) contains: OPTION_DEFAULT_ROUTER_LIST, option-len, router-address, router-lifetime, lla_len (link-layer address length) and, optionally, router_link_layer_address. As this option contains a list, the pattern containing router_address, router_lifetime, lla_len and optionally router_link_layer_address can be repeated.