Project Overview

Project Name: DHCPv6
Student: Kavya Bhat
Mentors: Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana
Google page: https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn
Project Goals: The project aims to implement DHCP for IPv6 (DHCPv6), which is used in IPv6 networks for address configuration on devices, and allows for central management of the network. ns-3 has a model for DHCP, which is used in IPv4 networks for address configuration. In IPv6, stateless address autoconfiguration (SLAAC) may be used, but this does not allow one to manage addresses of hosts in a network. ns-3 currently does not have an implementation for DHCPv6, and the aim is to add functionality for this protocol.
Repository: https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24
About Me: I have just completed my undergrad at the National Institute of Technology Karnataka, Surathkal (NITK). I am currently exploring the domains of operating systems and computer networks. I have earlier worked on the Neighbor Discovery protocol, and on IPv6 deployment in the university network.
Project Proposal: Link

Milestones

The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:

Duration: Week 1 to Week 6

Create the Dhcp6Header class and add the member function implementations.
Create the Dhcp6Server class and add the necessary functionality.
Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.
Write unit tests for the new classes.

Duration: Week 7 to Week 10

Duration: Week 11 to Week 12

Duration: May 1 to May 26

Worked on the design document, and discussed some of the considerations:
- Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? Section 18 of RFC 8415 suggests that DHCPv6 clients may operate independently, even when RAs are not received.
- Do we need to prevent SLAAC on global addresses? Infoblox Blog mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)
- Ensuring that routers use the correct flag in the RA.
- DUID format to be used for the Client / Server Identifiers: DUID based on Link-Layer address
Testing the DHCPv6 application and message exchanges:
- Before starting the client and server applications, test DHCPv6 header serialization and deserialization.
- Test stateful DHCPv6 (four message exchange) between the client and server.
- Test stateless DHCPv6 (Information-Request / Reply messages).
Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.
Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.
Commit: Classes for header and options

Duration: May 27 - June 2

Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)
- Doubt: How do we verify that the hardware type in the DUID is valid according to the standard IANA Hardware types?
Implemented member methods to add options to the DHCPv6 header.
Tested header serialization and deserialization to ensure options are added correctly (sanity test!).
Considerations for client and server implementations:
- Configure the rebind / renew timers carefully.
- Client state (waiting for address lease, configuring the refresh state) will need to be maintained.
Commits: Implemented following sections of RFC 8415 options.
- Identifier Options, Elapsed time options
- IANA, IATA, IA Address options

Duration: June 3 - June 9

Implemented a minimal DHCPv6 client that:
- Binds a UDP socket to the specified NetDevice.
- Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.
Implemented a minimal DHCPv6 server that:
- Binds a UDP socket to the All Nodes multicast address.
- On receiving a packet from the client, the server logs the information if the message type is SOLICIT.
Implemented a DHCPv6 helper that:
- Installs the DHCPv6 client on a given set of nodes in a NodeContainer.
- Installs the DHCPv6 server on a specified node.
Commits: Minimal DHCPv6 client and server
To be done:
- Send a Solicit message (including the correct options according to RFC 8415) from the client, and verify that an Advertise message can be received from the server.
- Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr<NetDevice> for the same.
- (Future work) Consider how to deal with multiple interfaces on a single node. For initial simplicity, we assume that the node has a single interface.