GSOC2024DHCPv6

From Nsnam
Jump to navigation Jump to search

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2024 projects

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:

Phase 1

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.

Phase 2

Duration: Week 7 to Week 10

  • Extend the implementation to support additional options in DHCPv6.
  • Work on the tests and examples for the new application model.

Phase 3

Duration: Week 11 to Week 12

  • Fix any failing tests, and add additional tests as required.
  • Add documentation for the DHCPv6 model.

Weekly Reports

Community Bonding Period

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

Week 1

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.

Week 2

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.

Week 3

Duration: June 10 - June 16

  • Added the Boot() method to the client for sending a Solicit message on starting the application, and a SendAdvertise() method to the server.
  • Modified the DHCPv6 helper and test case to allow users to define the required address pools.
  • Added methods to the client and server handle Request / Reply message exchange to the client and server.
    • Client method SendRequest() - selects the first address pool from the Advertise message, and includes it in the IA_NA option. Note: Need to study RFC 8415 to understand when the server includes multiple IA Address Options, and how the client decides which addresses are to be requested.
    • Client method AcceptReply() - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.
    • Commit: Request, Reply message exchange
  • Added an example for DHCPv6 in src/internet-apps/examples/
    • A packet capture on the server and client nodes helped me notice that the bytes were being written in the wrong order, since WriteU16() or WriteU32() writes the lower order bytes first. Fixed the header serialization accordingly.
    • Commit: DHCPv6 example
  • Discussed with mentors about how to store lease information. Decided to create another class for easily storing and handling multiple address pools and the corresponding leases' information.
  • To-do:
    • Design the class for storing lease information, and refactor DHCPv6 server accordingly.
    • Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.
    • Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.

Week 4

Duration: June 17 - June 23

  • Refactored the server to store lease information in a separate class. Each object of this class would contain:
    • Subnet information: Prefix, Range of addresses.
    • Lease information: To track addresses leased from the subnet, client DUID, lease time.
    • Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.
    • Declined addresses: To track addresses that have been declined by a client. (To check in RFC: Does it make sense to offer these again to the same client, when it sends a new Request to the server?)
    • Commit: Refactored server
  • Fixed the method of leasing addresses from the server. New process followed is:
    • Check if previously expired addresses are available. Offer an address from this list.
    • Else, obtain the latest leased address (the last address from the LeasedAddresses list). Increment this address by 1, and offer it to the client.
      • Note: Used bit operations to 'increment' the address, as IPv6 addresses are stored as an array of bytes. Worked with a couple of minimal tests, but is to be further validated.
  • Added an event m_solicitEvent to schedule periodic Solicit messages from the client. These events are cancelled when the client receives an Advertise message from the server, or if the client application is stopped.
  • Commit: Fix leasing method, add periodic Solicit event

Week 5

Duration: June 24 - June 30

  • Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.
  • Added a Renew event for the client to renew (and extend the lifetime of) the leased address.
  • Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).
  • Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.
  • Commits:
  • Changes to be made:
    • The client should do duplicate address detection before accepting the offered address from the DHCPv6 server. In case a duplicate address is detected, it should send a Decline message.
    • Clean-up of expired leases: Change lease information status from "active" to "expired" with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.
    • Test working of application with multiple clients sending requests to a single server.

Week 6

Duration: July 1 - July 7

  • Created a MR to add a TracedCallback to Icmpv6L4Protocol, to return the invalidated address when DAD fails.
  • Added a Release event for the client to stop using expired leases, and indicate the same to the server. On the server, created a periodic lease clean-up event that removes all expired leases from the leased address information. Commit: Release event, lease clean-up event
    • Thoughts - We might not want a periodic event to run. Instead, could just clean up the lease information just before adding information pertaining to a newly leased address.
  • The client now processes the Reply message from the server, and sends a Decline in case a duplicate address is detected on the link. Commit: Perform DAD before accepting offered address
  • Added the Status Code option, which is required in the Decline message (sent by the client) and the Reply message (sent by the server in response to Release / Decline). Commit: Add status code option, handle Decline message
  • Added a short validation method in the client that logs whether the bindings in the server were updated successfully, on receiving a Release / Decline. Commit: Validate status codes in Reply.

Week 7

Duration: July 8 - July 14

Week 8

Duration: July 15 - July 21

  • Refactored the code for Decline messages and accepting the address offer. The client now uses the DadFailure and DadSuccess callbacks. Commit: Use DAD callbacks
  • The DUID initialization earlier assumed that a link-layer address would be of the type Mac48Address. It has been changed to use any address length.
    • Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.
    • Commit: Handle any address length in DUID
  • The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:
  • Initial documentation has been added for the DHCPv6 application. Commit: Documentation outline

Week 9

Duration: July 22 - July 28

Week 10

Duration: July 29 - August 4

  • Improved the code for cleaning up leases periodically and updating lease bindings. Commit: Code cleanup
  • Added the client DUID in the expired address information. This would allow clients to obtain the same addresses that were earlier offered by the server. Commit: Add client DUID in ExpiredAddresses
  • Decided to use a separate class for the DUID. This would make for easier control over the DUID types (currently DUID-LL and DUID-LLT). Commit: Separate DUID class
  • Opened a draft MR for stateful DHCPv6.

Week 11

Duration: August 5 - August 11

  • Modified the class for DUID.
    • The aim was to use a general byte array, instead of remaining confined to the Address type.
    • A DUID can now be set by passing a byte array as the identifier, along with its length - using the SetDuid() method. (Note: The client and server still use the NetDevice address as the DUID, only the internal handling has been modified).
    • The class has also been moved to new files, namely dhcp6-duid.h and dhcp6-duid.cc.
    • Commit: Modified DUID class
  • IdentifierOptions earlier used a smart pointer to the DUID (Ptr<Duid>). The code has been modified to use a object of type Duid instead.

Week 12 (and 13?)

Duration: August 12 - August 20

  • Refactored the DUID class to:
    • make it a child of the Header class. By serializing and deserializing the DUID independently, it allows for easier handling in the client and server as well.
    • use a std::vector<uint8_t> instead of an array (it went through a phase of being uint8_t* as well). According to RFC 8415, a DUID can be up to 128 bytes, so using a vector might be the best approach.
    • Commits: Refactored DUID class, Use vector for identifier
  • Opened an MR for adding a TracedCallback that can be used to trigger the DHCPv6 client to start sending Solicits.
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&oldid=13264"