<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Kavyabhat</id>
	<title>Nsnam - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Kavyabhat"/>
	<link rel="alternate" type="text/html" href="https://www.nsnam.org/wiki/Special:Contributions/Kavyabhat"/>
	<updated>2026-04-09T12:48:53Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.8</generator>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13273</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13273"/>
		<updated>2024-08-23T17:55:02Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:shattered.feelings@gmail.com Alberto Gallegos Ramonet], [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
=== Acknowledgements ===&lt;br /&gt;
&lt;br /&gt;
I would like to thank all my mentors and the ns-3 developers for providing guidance and advice throughout the project, and for the opportunity to contribute to ns-3 through GSoC '24. While working on this project, I learned a lot of new concepts and got comfortable with navigating huge codebases. Weekly discussions with the mentors were insightful and exciting, and I'm glad to have extensively discussed multiple topics over the entire duration. I would also like to thank Google for this amazing opportunity.&lt;br /&gt;
&lt;br /&gt;
=== Challenges Faced ===&lt;br /&gt;
&lt;br /&gt;
While most of the project aspects were straightforward, there were a couple of sections where I got (highly) confused about how to design and implement features - namely, the DHCP Unique Identifier and the Identity Association Identifier classes. Reaching out to the mentors on Zulip allowed me to discuss, understand and progress easily whenever I was stuck. At times, I sought their help to debug programs and locate issues, and this helped a great deal as well.&lt;br /&gt;
&lt;br /&gt;
=== Suggestions for Future Contributors ===&lt;br /&gt;
&lt;br /&gt;
* The community bonding period is important! &lt;br /&gt;
** Reach out to your mentors early, to discuss the timeline and any prior obligations during the coding period. &lt;br /&gt;
** Try to identify areas that require more attention than you would expect. Also read through the codebase, and familiarize yourself with the relevant sections that you would use regularly.&lt;br /&gt;
&lt;br /&gt;
* Seek help at the right time.&lt;br /&gt;
** If you've put in a lot of effort but are still stuck on an issue, don't delay asking for help. There's a high chance someone else has encountered the same issue and can help you solve it.&lt;br /&gt;
&lt;br /&gt;
* Enjoy! Your GSoC project will help you learn and have a fun experience with the organization. While tasks may seem daunting at first, you'll have great mentors to guide you. Make the most out of the opportunity!&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13272</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13272"/>
		<updated>2024-08-23T17:50:20Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
=== Acknowledgements ===&lt;br /&gt;
&lt;br /&gt;
I would like to thank all my mentors and the ns-3 developers for providing guidance and advice throughout the project, and for the opportunity to contribute to ns-3 through GSoC '24. While working on this project, I learned a lot of new concepts and got comfortable with navigating huge codebases. Weekly discussions with the mentors were insightful and exciting, and I'm glad to have extensively discussed multiple topics over the entire duration. I would also like to thank Google for this amazing opportunity.&lt;br /&gt;
&lt;br /&gt;
=== Challenges Faced ===&lt;br /&gt;
&lt;br /&gt;
While most of the project aspects were straightforward, there were a couple of sections where I got (highly) confused about how to design and implement features - namely, the DHCP Unique Identifier and the Identity Association Identifier classes. Reaching out to the mentors on Zulip allowed me to discuss, understand and progress easily whenever I was stuck. At times, I sought their help to debug programs and locate issues, and this helped a great deal as well.&lt;br /&gt;
&lt;br /&gt;
=== Suggestions for Future Contributors ===&lt;br /&gt;
&lt;br /&gt;
* The community bonding period is important! &lt;br /&gt;
** Reach out to your mentors early, to discuss the timeline and any prior obligations during the coding period. &lt;br /&gt;
** Try to identify areas that require more attention than you would expect. Also read through the codebase, and familiarize yourself with the relevant sections that you would use regularly.&lt;br /&gt;
&lt;br /&gt;
* Seek help at the right time.&lt;br /&gt;
** If you've put in a lot of effort but are still stuck on an issue, don't delay asking for help. There's a high chance someone else has encountered the same issue and can help you solve it.&lt;br /&gt;
&lt;br /&gt;
* Enjoy! Your GSoC project will help you learn and have a fun experience with the organization. While tasks may seem daunting at first, you'll have great mentors to guide you. Make the most out of the opportunity!&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13271</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13271"/>
		<updated>2024-08-22T00:52:36Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Suggestions for Future Contributors */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
I would like to thank all my mentors and the ns-3 developers for providing guidance and advice throughout the project, and for the opportunity to contribute to ns-3 through GSoC '24. While working on this project, I learned a lot of new concepts and got comfortable with navigating huge codebases. Weekly discussions with the mentors were insightful and exciting, and I'm glad to have extensively discussed multiple topics over the entire duration. I would also like to thank Google for this amazing opportunity.&lt;br /&gt;
&lt;br /&gt;
== Challenges Faced ==&lt;br /&gt;
&lt;br /&gt;
While most of the project aspects were straightforward, there were a couple of sections where I got (highly) confused about how to design and implement features - namely, the DHCP Unique Identifier and the Identity Association Identifier classes. Reaching out to the mentors on Zulip allowed me to discuss, understand and progress easily whenever I was stuck. At times, I sought their help to debug programs and locate issues, and this helped a great deal as well.&lt;br /&gt;
&lt;br /&gt;
== Suggestions for Future Contributors ==&lt;br /&gt;
&lt;br /&gt;
* The community bonding period is important! &lt;br /&gt;
** Reach out to your mentors early, to discuss the timeline and any prior obligations during the coding period. &lt;br /&gt;
** Try to identify areas that require more attention than you would expect. Also read through the codebase, and familiarize yourself with the relevant sections that you would use regularly.&lt;br /&gt;
&lt;br /&gt;
* Seek help at the right time.&lt;br /&gt;
** If you've put in a lot of effort but are still stuck on an issue, don't delay asking for help. There's a high chance someone else has encountered the same issue and can help you solve it.&lt;br /&gt;
&lt;br /&gt;
* Enjoy! Your GSoC project will help you learn and have a fun experience with the organization. While tasks may seem daunting at first, you'll have great mentors to guide you. Make the most out of the opportunity!&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13270</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13270"/>
		<updated>2024-08-22T00:43:15Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Challenges Faced */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
I would like to thank all my mentors and the ns-3 developers for providing guidance and advice throughout the project, and for the opportunity to contribute to ns-3 through GSoC '24. While working on this project, I learned a lot of new concepts and got comfortable with navigating huge codebases. Weekly discussions with the mentors were insightful and exciting, and I'm glad to have extensively discussed multiple topics over the entire duration. I would also like to thank Google for this amazing opportunity.&lt;br /&gt;
&lt;br /&gt;
== Challenges Faced ==&lt;br /&gt;
&lt;br /&gt;
While most of the project aspects were straightforward, there were a couple of sections where I got (highly) confused about how to design and implement features - namely, the DHCP Unique Identifier and the Identity Association Identifier classes. Reaching out to the mentors on Zulip allowed me to discuss, understand and progress easily whenever I was stuck. At times, I sought their help to debug programs and locate issues, and this helped a great deal as well.&lt;br /&gt;
&lt;br /&gt;
== Suggestions for Future Contributors ==&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13269</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13269"/>
		<updated>2024-08-22T00:39:19Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Acknowledgements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
&lt;br /&gt;
I would like to thank all my mentors and the ns-3 developers for providing guidance and advice throughout the project, and for the opportunity to contribute to ns-3 through GSoC '24. While working on this project, I learned a lot of new concepts and got comfortable with navigating huge codebases. Weekly discussions with the mentors were insightful and exciting, and I'm glad to have extensively discussed multiple topics over the entire duration. I would also like to thank Google for this amazing opportunity.&lt;br /&gt;
&lt;br /&gt;
== Challenges Faced ==&lt;br /&gt;
== Suggestions for Future Contributors ==&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13268</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13268"/>
		<updated>2024-08-21T12:16:45Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;br /&gt;
&lt;br /&gt;
== My Experience ==&lt;br /&gt;
&lt;br /&gt;
== Acknowledgements ==&lt;br /&gt;
== Challenges Faced ==&lt;br /&gt;
== Suggestions for Future Contributors ==&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13267</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13267"/>
		<updated>2024-08-21T12:07:55Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Phase 2 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
&lt;br /&gt;
During this phase, I worked on improving and refactoring the code as per suggestions from and discussions with the mentors. The main focus was on using a common Unique Identifier (DUID) across all interfaces on a single node, and correctly handling Identity Association Identifiers (IAIDs).&lt;br /&gt;
&lt;br /&gt;
In this phase, we also worked on the documentation for DHCPv6. Along with this, we decided to start verifying if DHCPv6 would work on 6LoWPAN and LR-WPAN using an example.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 1 (in review)], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 2]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13266</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13266"/>
		<updated>2024-08-21T11:45:01Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Phase 1 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
We decided to focus on implementing stateful DHCPv6 as part of the GSoC project.During this phase, we initially set up a minimal four message exchange between a DHCPv6 client and server, where only the mandatory options were included in the Solicit / Advertise / Request / Reply messages.&lt;br /&gt;
Initially, the address lease information was stored as part of the DHCPv6 server. However, we refactored the server to use a newly created class called ''LeaseInfo'' to simplify address pool management.&lt;br /&gt;
&lt;br /&gt;
During this period, we also wrote a new example for DHCPv6. Using this example, we validated that address offers, expiry and renew events occurred as expected.&lt;br /&gt;
&lt;br /&gt;
RFC 8415 specifies that a client node should perform duplicate address detection before &lt;br /&gt;
accepting any address that is offered to it. Towards this end, we added ''TracedCallback''s in the ''Icmpv6L4Protocol'' class, and used these callbacks in the DHCPv6 client.&lt;br /&gt;
&lt;br /&gt;
MRs submitted: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 1], [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 2]&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13265</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13265"/>
		<updated>2024-08-21T01:20:14Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the code written during GSoC, named [https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 gsoc-24].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024DHCPv6 GSOC2024DHCPv6]&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Community Bonding Period ==&lt;br /&gt;
&lt;br /&gt;
=== Plan and Action Points ===&lt;br /&gt;
During this phase, we ironed out details on how to begin working on the project:&lt;br /&gt;
&lt;br /&gt;
* Scheduled a weekly video call for doubts and discussions.&lt;br /&gt;
* Discussed the ideas in the proposal to decide which features of DHCPv6 were to be supported, and which were not. We decided to focus on stateful DHCPv6 for the project.&lt;br /&gt;
* Began working on a design document for the project. &lt;br /&gt;
* Decided to maintain a single branch, gsoc-24, on the fork for all the work done over the entire timeline.&lt;br /&gt;
&lt;br /&gt;
=== Prior to Coding Phase ===&lt;br /&gt;
* Read through RFC 8415 to understand the required and relevant sections to be implemented.&lt;br /&gt;
* Coded a rough outline of the DHCPv6 Header and Options classes to better understand edge cases and make design decisions of how to handle all the DHCPv6 options.&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13264</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13264"/>
		<updated>2024-08-21T00:15:23Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;br /&gt;
&lt;br /&gt;
=== Week 8 ===&lt;br /&gt;
'''Duration: ''' July 15 - July 21&lt;br /&gt;
* Refactored the code for Decline messages and accepting the address offer. The client now uses the ''DadFailure'' and ''DadSuccess'' callbacks. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/912e0147f9a1d5c5067faa4176f82d58e2d90c71 Use DAD callbacks]&lt;br /&gt;
* 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. &lt;br /&gt;
** Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/32a7157a05370f95ff11109eda9c7512c07390a8 Handle any address length in DUID]&lt;br /&gt;
* The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:&lt;br /&gt;
**[https://gitlab.com/kavbhat/ns-3-dev/-/commit/e9ba9ec3f521e8f26fa2c53522829cd301d87277 Code cleanup]&lt;br /&gt;
* Initial documentation has been added for the DHCPv6 application. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/22ed8e5f7287d8861d5b1c9d44b1c7473f4f764b Documentation outline]&lt;br /&gt;
&lt;br /&gt;
=== Week 9 ===&lt;br /&gt;
'''Duration: ''' July 22 - July 28&lt;br /&gt;
* Corrected the usage of IAIDs in IA_NA options based on [https://datatracker.ietf.org/doc/html/rfc8415#section-12 Section 12 of RFC 8415]. Each interface on a client uses a single IA_NA with a unique IAID.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/78592d5401eee1c1a35ec3a23ea270843fe6be28 IAID corrections]&lt;br /&gt;
* Changed the periodic Solicit message to use a TrickleTimer, such that the frequency of messages gradually decreases. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/9df2c2047429fda1a0957ed04df1b5b04b4b58af TrickleTimer for Solicits].&lt;br /&gt;
* Added further documentation for DHCPv6: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/77f512a27e4421174374266791b705b19e2a71c5 Update documentation]&lt;br /&gt;
&lt;br /&gt;
=== Week 10 ===&lt;br /&gt;
'''Duration: ''' July 29 - August 4&lt;br /&gt;
* Improved the code for cleaning up leases periodically and updating lease bindings. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/3ccdb3a5a3aa9975adc2cf2b9deb1bfdd1a33662 Code cleanup]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2be995514fc4e98ff39d718c723a3fb59d634f9 Add client DUID in ExpiredAddresses]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0f195c70623fe080ce64979b8156fe95c677669e Separate DUID class]&lt;br /&gt;
* Opened a draft [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 MR] for stateful DHCPv6.&lt;br /&gt;
&lt;br /&gt;
=== Week 11 ===&lt;br /&gt;
'''Duration: ''' August 5 - August 11&lt;br /&gt;
* Modified the class for DUID.&lt;br /&gt;
** The aim was to use a general byte array, instead of remaining confined to the ''Address'' type.&lt;br /&gt;
** 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).&lt;br /&gt;
** The class has also been moved to new files, namely ''dhcp6-duid.h'' and ''dhcp6-duid.cc''.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/be3aa7545d2a8b2b54e964b6cd73c46bdbfb03fe Modified DUID class]&lt;br /&gt;
* ''IdentifierOptions'' earlier used a smart pointer to the DUID (''Ptr&amp;lt;Duid&amp;gt;''). The code has been modified to use a object of type ''Duid'' instead.&lt;br /&gt;
&lt;br /&gt;
=== Week 12 (and 13?) ===&lt;br /&gt;
'''Duration: ''' August 12 - August 20&lt;br /&gt;
* Refactored the DUID class to:&lt;br /&gt;
** 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.&lt;br /&gt;
** use a ''std::vector&amp;lt;uint8_t&amp;gt;'' 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.&lt;br /&gt;
** Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/648b58492c17b821b3cc7cd372cfb6f13b7aaa7c Refactored DUID class], [https://gitlab.com/kavbhat/ns-3-dev/-/commit/50d1278897a19ebacdcef384ac7a89707f989f71 Use vector for identifier]&lt;br /&gt;
* Opened an [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 MR] for adding a ''TracedCallback'' that can be used to trigger the DHCPv6 client to start sending Solicits.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13261</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13261"/>
		<updated>2024-08-20T01:26:05Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;br /&gt;
&lt;br /&gt;
== Merge Requests, Commits, and Project Details ==&lt;br /&gt;
&lt;br /&gt;
We maintained a single branch for all the GSoC work, named [https://gitlab.com/ameyanrd/ns-3-dev/-/tree/gsoc-21 ''gsoc-21''].&lt;br /&gt;
&lt;br /&gt;
Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2021NixVector ''GSOC2021NixVector'']&lt;br /&gt;
&lt;br /&gt;
Proposal: [https://drive.google.com/file/d/18IpyX-UdrX7v_Xh-jpEixdEExq_0gsZa/view?usp=sharing ''link'']&lt;br /&gt;
&lt;br /&gt;
To create a Merge Request, I picked the particular set of related commits from ''gsoc-21'', applied them on another master-derived branch, and then made an MR.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Merge Requests&lt;br /&gt;
|-&lt;br /&gt;
! No. !! Name !! Status !! Commit&lt;br /&gt;
|-&lt;br /&gt;
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 internet: Add TracedCallback to trace address state on DAD completion] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/cc7fc01328238de13255c9e267df7c2b6dff4318]&lt;br /&gt;
|-&lt;br /&gt;
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 internet: Add TracedCallback to trace valid address after DAD] || Merged || [https://gitlab.com/nsnam/ns-3-dev/-/commit/4af7b6d2d073c79426e1f23d19b1ccc9ed8b35d2], [https://gitlab.com/nsnam/ns-3-dev/-/commit/7c4b0dac96c4500f1e1979d7274a38208e92bdd2]&lt;br /&gt;
|-&lt;br /&gt;
| [3] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 Draft: GSoC 24 - DHCPv6] || Draft || --&lt;br /&gt;
|-&lt;br /&gt;
| [4] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2102 internet: Add TracedCallback for interface on receiving M flag in RA] || Approved || --&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13260</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13260"/>
		<updated>2024-08-19T18:32:04Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' [mailto:kavyabhat@gmail.com Kavya Bhat]&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
&lt;br /&gt;
The project aimed 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 but currently does not have an implementation for DHCPv6, and the goal is to add functionality for this protocol.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&amp;diff=13259</id>
		<title>Summer Projects</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&amp;diff=13259"/>
		<updated>2024-08-16T14:23:02Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Google Summer of Code 2024 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
The project coordinates a few summer coding programs in which student developers are paired with mentors to produce code over the summer.&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2024 =&lt;br /&gt;
&lt;br /&gt;
ns-3 is mentoring three projects for 2024:&lt;br /&gt;
&lt;br /&gt;
* '''Joao Albuquerque''', [[GSOC2024Channels5G | 5G NR Module Benchmark and Analysis for Distinct Channel Models]], mentored by Biljana Bojovic, Amir Ashtari, and Gabriel Ferreira&lt;br /&gt;
* '''Kavya Bhat''', [[GSOC2024DHCPv6 | DHCPv6]], mentored by Tommaso Pecorella, Alberto Gallegos Ramonet, and Manoj Kumar Rana: '''''[[GSOC2024DHCPv6FinalReport | Final report]]'''''&lt;br /&gt;
* '''Hyerin Kim''',  [[GSOC2024RLUsability5G | Enhancement of RL Approach Accessibility in NR]], mentored by Katerina Koutlia, Amir Ashtari, Biljana Bojovic, and Gabriel Ferreira&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2024Projects | Project Ideas Page]]&lt;br /&gt;
* [[GSOC2024ContributorGuide | ns-3's GSoC Contributor Guide]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2023 =&lt;br /&gt;
&lt;br /&gt;
The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.&lt;br /&gt;
&lt;br /&gt;
We had three successful student projects for 2023; you can read their final reports below:&lt;br /&gt;
&lt;br /&gt;
* '''Giovanni Grieco''', [[GSOC20235GUsability | IUNS-3 5G NR: Improving the Usability of ns-3's 5G NR Module]], mentored by Tom Henderson, Katerina Koutlia, and Biljana Bojovic:  '''''[[GSOC20235GUsabilityFinalReport | Final report]]'''''&lt;br /&gt;
* '''Raghuram Kannan''', [[GSOC2023NetAnim | Dynamic device registration for NetAnim simulation animations]], mentored by Tommaso Pecorella and Manoj Kumar Rana: '''''[[GSOC2023NetAnimFinalReport | Final report]]'''''&lt;br /&gt;
* '''Muyuan Shen''', [[GSOC2023ns3-ai | ns3-ai enhancements]], mentored by Collin Brady and Hao Yin: '''''[[GSOC2023ns3-aiFinalReport | Final report]]'''''&lt;br /&gt;
&lt;br /&gt;
We reviewed seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page.  For future reference, below is our ideas page and contributor's guide.&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2023Projects | Project Ideas Page]]&lt;br /&gt;
* [[GSOC2023ContributorGuide | ns-3's GSoC Contributor Guide]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2022 =&lt;br /&gt;
&lt;br /&gt;
The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.&lt;br /&gt;
&lt;br /&gt;
Two contributors completed projects with ns-3 in the 2022 Google Summer of Code.&lt;br /&gt;
&lt;br /&gt;
* '''Matteo Pagin''', [[GSOC2022Channel | A simplified channel and beamforming model for ns-3]], mentored by Sandra Lagen, Biljana Bojovic, and Michele Polese  '''''[https://pagmatt.github.io/blog/2022/gsoc2022 Final Report]'''''&lt;br /&gt;
* '''Zhiheng Dong''', [[GSOC2022PerfectArp | Perfect ARP and NDP]], mentored by Tommaso Pecorella, Ameya Deshpande,and Manoj Kumar Rana '''''[[GSOC2022NeighborCacheFinalReport | Final Report]]'''''&lt;br /&gt;
&lt;br /&gt;
One additional project was started but did not progress past the midterm evaluation:&lt;br /&gt;
&lt;br /&gt;
* '''Akash Mondal''', [[GSOC2022TCPMaximumSegmentSize | TCP maximum segment size (MSS) improvements]], mentored by Mohit Tahiliani, Bhaskar Kataria, and Vivek Jain&lt;br /&gt;
&lt;br /&gt;
We received seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page.  For future reference, below is our ideas page and contributor's guide.&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2022Projects | Project Ideas Page]]&lt;br /&gt;
* [[GSOC2022ContributorGuide | ns-3's GSoC Contributor Guide]]&lt;br /&gt;
&lt;br /&gt;
= ns-3 Summer of Code 2022 =&lt;br /&gt;
&lt;br /&gt;
ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code.  Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC.    &lt;br /&gt;
&lt;br /&gt;
* '''Chandrakant Jena,''' ''Ping and Ping6 Enhancements for ns-3:'' '''''[[NSOC2022Ping | project wiki page ]]''''' mentored by Tommaso Pecorella and Tom Henderson&lt;br /&gt;
&lt;br /&gt;
The project by Chandrakant was completed successfully in December 2022, with six commits made to ns-3-dev starting with [https://gitlab.com/nsnam/ns-3-dev/-/commit/da107e04eeb0c12631eadda6a30ad1a33b7f0931 commit da107e04].  The project added a '''[https://www.nsnam.org/docs/doxygen/d6/dbe/classns3_1_1_ping.html new Ping application]''', helper class, example program, unit test, and [https://www.nsnam.org/docs/models/html/internet-apps.html#ping documentation].&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2021 =&lt;br /&gt;
&lt;br /&gt;
Three students successfully completed projects in [https://summerofcode.withgoogle.com/organizations/4672908493848576/ Google Summer of Code 2021].&lt;br /&gt;
&lt;br /&gt;
* '''Parth Pratim Chatterjee,''' ''Direct Code Execution Modernization:'' '''''[[GSOC2021DCE | project wiki page]]''''' '''--''' '''''[https://ns-3-dce-linux-upgrade.github.io/ Final report]'''''&lt;br /&gt;
* '''Ameya Deshpande,''' ''IPv6 Nix-Vector Routing:'' '''''[[GSOC2021NixVector | project wiki page]]''''' '''--''' '''''[https://www.nsnam.org/wiki/GSOC2021NixVectorFinalReport Final report]'''''&lt;br /&gt;
* '''Akshit Patel,''' ''Add logging support to Simulation Execution Manager (SEM):'' '''''[[GSOC2021SEM | project wiki page]]''''' '''--''' '''''[https://akshitpatel01.github.io/GSoC-2021-Report/ Final report]'''''&lt;br /&gt;
&lt;br /&gt;
For reference, below were the 2021 project ideas and the 2021 student guide:&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2021StudentGuide | Student Guide]]&lt;br /&gt;
* [[GSOC2021Projects | Project Ideas Page]]&lt;br /&gt;
&lt;br /&gt;
= ns-3 Summer of Code 2021 =&lt;br /&gt;
&lt;br /&gt;
ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code.  Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC.  The commitments are similar; students and mentors are expected to define and work towards a mergeable project goal by the end of the summer.  The program is offered to 'honorable mention' GSoC proposals (i.e., proposals that we would have selected had we received more student slots from Google) and for other reasons such as a contributor's ineligibility for GSoC.&lt;br /&gt;
&lt;br /&gt;
* '''Nitya Chandra,''' ''Enable IPv6 support for ad-hoc routing protocols in ns-3:'' '''''[[NSOC2021Ipv6 | project wiki page ]]''''' '''Note: project did not complete'''&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2020 =&lt;br /&gt;
&lt;br /&gt;
Four students successfully completed [https://summerofcode.withgoogle.com/ Google Summer of Code 2020] projects:&lt;br /&gt;
&lt;br /&gt;
* '''Shivamani Patil,''' ''App Store Improvements:'' '''''[https://shivamanipatil.github.io/gsoc-2020-report/ final report], [[GSOC2020AppStore | project wiki page]]'''''&lt;br /&gt;
* '''Ananthakrishan S,''' ''NetDevice up/down consistency and event chain:'' '''''[https://ananthu-dev.github.io/net-device-consistency-gsoc-2020/ final report], [[GSOC2020NetDevice | project wiki page]]'''''&lt;br /&gt;
* '''Bhaskar Kataria,''' ''SCE AQMs and TCP along with CNQ-CodelAF and LFQ'' '''''[https://bhaskar792.github.io/GSoC-2020-Report/ final report], [[GSOC2020AQM | project wiki page]]'''''&lt;br /&gt;
* '''Deepak K,''' ''TCP Prague model for ns-3'', '''''[https://deepakkavoor.github.io/gsoc-2020-prague/ final report], [[GSOC2020Prague | project wiki page]]'''''&lt;br /&gt;
&lt;br /&gt;
For reference, below were the 2020 project ideas and the 2020 student guide:&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2020StudentGuide | Student Guide]]&lt;br /&gt;
* [[GSOC2020Projects | Project Ideas Page]]&lt;br /&gt;
&lt;br /&gt;
= ns-3 Summer of Code 2020 =&lt;br /&gt;
&lt;br /&gt;
These projects are unfunded but are mentored in a manner similar to GSoC, at a lesser pace than the 12-week GSoC program.&lt;br /&gt;
&lt;br /&gt;
* Muhammad Iqbal Rochman, [[NSOC2020WifiPHY | Wi-Fi PHY Restructure]]  '''Note:''' This project successfully completed.&lt;br /&gt;
* Harsha Sharma, [[NSOC2020L4SEvaluation | L4S evaluation framework]]  '''Note:''' This project continued through fall 2020 but did not yet merge.&lt;br /&gt;
* Rahul Bothra, [[NSOC2020Routing | Routing for community wireless networks]] '''Note:''' Project discontinued in August 2020.&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2019 =&lt;br /&gt;
&lt;br /&gt;
ns-3 participated in Google Summer of Code 2019 with four student projects:&lt;br /&gt;
&lt;br /&gt;
* Apoorva Bhargava, [[GSOC2019TCPTestingAndAlignment | Testing and Alignment of ns-3 TCP with Linux TCP]]&lt;br /&gt;
* Mishal Shah, [[GSOC2019AppStore | Improving the ns-3 AppStore and linking with bake]]&lt;br /&gt;
* Tommaso Zugno, [[GSOC2019ThreeGPPChannel | Integration of the 3GPP TR 38.901 channel model in the ns-3 spectrum module]]&lt;br /&gt;
* Liangcheng Yu, [[GSOC2019DCN | Framework of Studying Flow Completion Time Minimization for Data Center Networks in ns-3]]&lt;br /&gt;
&lt;br /&gt;
Below are project ideas and the 2019 student guide:&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2019StudentGuide | ns-3 GSoC student guide]]&lt;br /&gt;
* [[GSOC2019Projects | Project Ideas Page]]&lt;br /&gt;
&lt;br /&gt;
= European Space Agency Summer of Code in Space (SOCIS) 2019 =&lt;br /&gt;
&lt;br /&gt;
ns-3 ultimately was not selected for funding for SOCIS 2019.  Below is an archive of our student guide, for future reference.&lt;br /&gt;
&lt;br /&gt;
* [[SOCIS2019 | ns-3 SOCIS student guide]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2018 =&lt;br /&gt;
&lt;br /&gt;
ns-3 participated in the 2018 edition of Google Summer of Code, with five students:&lt;br /&gt;
&lt;br /&gt;
* WenYing Dai, [[GSOC2018AccECN_ECN++ | Implementation of AccECN and ECN++ in ns-3]]&lt;br /&gt;
* Muhammad Iqbal CR, [[GSOC2018Coexistence | Merging and Improvement of LTE and Wi-Fi Coexistence Module]]&lt;br /&gt;
* Sourabh Jain, [[GSoC2018_DCE_Upgrade | Direct Code Execution upgrade]]&lt;br /&gt;
* Davide Magrin, [[GSoC2018:_A_Simulation_Execution_Manager_for_ns-3 | A simulation execution manager for ns-3]]&lt;br /&gt;
* Jude Niroshan, [[GSoC2018:Trust-based_routing_protocols_framework | Trust-based routing protocols framework]]&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2018Projects | Project Ideas Page]]&lt;br /&gt;
* [[GSOC2018StudentGuide | Student Application Guide]]&lt;br /&gt;
&lt;br /&gt;
= European Space Agency Summer of Code in Space (SOCIS) 2017 =&lt;br /&gt;
&lt;br /&gt;
ns-3 has been accepted to the 2017 ESA Summer of Code in Space, with student Pasquale Imputato (mentored by Tommaso Pecorella).  The project successfully completed in October 2017 (details in the below wiki project page).&lt;br /&gt;
&lt;br /&gt;
* [[SOCIS2017 | project page]]&lt;br /&gt;
* [https://codereview.appspot.com/330220043/ Final code review]&lt;br /&gt;
&lt;br /&gt;
The original project ideas page is posted below.&lt;br /&gt;
&lt;br /&gt;
* [[SOCIS2017Projects#Project_Ideas | Project Ideas page]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2017 =&lt;br /&gt;
&lt;br /&gt;
ns-3 was fortunate to mentor five outstanding students for the 2017 edition of [https://developers.google.com/open-source/gsoc/ Google Summer of Code].&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2017AcceptedProjects | Accepted Projects]]&lt;br /&gt;
== Final reports ==&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/013916.html ns-3 App Store] by Abhijith Anilkumar&lt;br /&gt;
* [https://www.nsnam.org/wiki/GSOC2017Lte#Project_summary Enabling LTE CA handover to secondary cell] by Alexander Krotov&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013929.html TCP Prague] by Shravya Ks&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013918.html LTE and IPv6 support] by Manoj Kumar Rana&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013921.html TBF and HHF] by Surya Seetharaman&lt;br /&gt;
&lt;br /&gt;
== Phase 2 reports ==&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014038.html BCube and FatTree topology helpers (component of TCP Prague project)]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014054.html Implementation of TBF and HHF]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014047.html Enabling LTE CA handover to secondary cell, Phase 2]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014042.html ns-3 App Store]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014049.html Mobile IPv6 implementation with LTE support (report)]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014058.html Mobile IPv6 implementation with LTE support (review request)]&lt;br /&gt;
== Phase 1 reports ==&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013980.html Data Center TCP (component of TCP Prague project)]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013982.html Implementation of TBF and HHF traffic control]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013983.html Enabling LTE CA handover to secondary cell, Phase 1]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013985.html ns-3 App Store]&lt;br /&gt;
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013987.html Mobile IPv6 implementation with LTE support]&lt;br /&gt;
== Background ==&lt;br /&gt;
Below is some information that was used during the application phase.&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2017Projects | Project Ideas Page]]&lt;br /&gt;
* [[GSOC2017StudentGuide | Student Application Guide]]&lt;br /&gt;
&lt;br /&gt;
= European Space Agency Summer of Code in Space (SOCIS) 2016 =&lt;br /&gt;
&lt;br /&gt;
ns-3 had one student (Michael Di Perna) successfully complete the 2016 [http://sophia.estec.esa.int/socis/ ESA Summer of Code in Space].  &lt;br /&gt;
&lt;br /&gt;
* [[SOCIS2016 | Project page]] for Optical Satellite Systems project&lt;br /&gt;
* [[SOCIS2016Projects#Project_Ideas | Project Ideas page]]&lt;br /&gt;
&lt;br /&gt;
= Mentored summer projects 2016 =&lt;br /&gt;
&lt;br /&gt;
ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis.  Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.&lt;br /&gt;
&lt;br /&gt;
* See [[MentoredProjects2016]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2016 =&lt;br /&gt;
&lt;br /&gt;
ns-3 was not selected for the 2016 [https://developers.google.com/open-source/gsoc/ Google Summer of Code].  We mentored two summer projects outside of GSoC.  Below were our materials prepared for our GSoC organizational application.&lt;br /&gt;
* [[GSOC2016Projects | Project ideas page]]&lt;br /&gt;
* [[GSOCStudentGuide | Student guide]]&lt;br /&gt;
&lt;br /&gt;
= Google Summer of Code 2015 =&lt;br /&gt;
&lt;br /&gt;
ns-3 was selected to participate in the 2015 [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code].  More information can be found on our Project Ideas page and our Student Guide.&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2015AcceptedProjects | Accepted projects]]&lt;br /&gt;
* [[GSOC2015Projects | Project ideas page]]&lt;br /&gt;
* [[GSOC2015StudentGuide | Student guide]]&lt;br /&gt;
&lt;br /&gt;
This year's students were announced on April 27, and all four successfully completed the program:&lt;br /&gt;
&lt;br /&gt;
* Melchiorre Danilo Abrignani, [[GSOC2015LTECA | Carrier Aggregation support for the LTE module]]&lt;br /&gt;
* Matthieu Coudron, [[GSOC2015MpTcpImplementation | Implementing multipath TCP (MPTCP) in ns3]]&lt;br /&gt;
* Natale Patriciello, [[GSOC2015TCPTest | TCP layer refactoring with automated test on RFC compliance and validation]]&lt;br /&gt;
* Vishwesh Rege, [[GSOC2015LrWpanMac | 802.15.4 realistic MAC and Energy Model]]&lt;br /&gt;
&lt;br /&gt;
= European Space Agency Summer of Code in Space (SOCIS) 2015 =&lt;br /&gt;
&lt;br /&gt;
ns-3 has been accepted to the 2015 [http://sophia.estec.esa.int/socis2015/ ESA Summer of Code in Space].  The ns-3 project had one student in SOCIS in each of 2013, 2014 and 2015.  However, the satellite channel models project for 2015 [[SOCIS2015 | Satellite channel models]] did not successfully complete.&lt;br /&gt;
&lt;br /&gt;
* [[SOCIS2015Projects | Project ideas page]] (for reference)&lt;br /&gt;
&lt;br /&gt;
= Mentored summer projects =&lt;br /&gt;
&lt;br /&gt;
ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis.  Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.&lt;br /&gt;
&lt;br /&gt;
We have one such mentored project in 2015:&lt;br /&gt;
&lt;br /&gt;
* Saswat Mishra, [[NeighborDiscoveryProject | Neighbor Discovery enhancements]]&lt;br /&gt;
&lt;br /&gt;
= Past summer projects =&lt;br /&gt;
&lt;br /&gt;
* [[GSOC2014AcceptedProjects | GSoC 2014 Accepted Projects]]&lt;br /&gt;
* [[SOCIS2014TCP | SOCIS 2014 Accepted Project]]&lt;br /&gt;
* [[MentoredProjects2014 | 2014 Mentored Projects]]&lt;br /&gt;
* [[SOCIS2013BundleProtocolProject | SOCIS 2013 Accepted Project]]&lt;br /&gt;
* [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]&lt;br /&gt;
* [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]&lt;br /&gt;
* [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]&lt;br /&gt;
* [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]&lt;br /&gt;
* [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]&lt;br /&gt;
* [https://developers.google.com/open-source/soc/2008/?csw=1#ns3 GSoC 2008 Accepted Projects]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13258</id>
		<title>GSOC2024DHCPv6FinalReport</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6FinalReport&amp;diff=13258"/>
		<updated>2024-08-16T14:22:33Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: Created page with &amp;quot;{{TOC}}  Back to  GSoC 2024 projects&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13257</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13257"/>
		<updated>2024-08-15T00:58:28Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;br /&gt;
&lt;br /&gt;
=== Week 8 ===&lt;br /&gt;
'''Duration: ''' July 15 - July 21&lt;br /&gt;
* Refactored the code for Decline messages and accepting the address offer. The client now uses the ''DadFailure'' and ''DadSuccess'' callbacks. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/912e0147f9a1d5c5067faa4176f82d58e2d90c71 Use DAD callbacks]&lt;br /&gt;
* 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. &lt;br /&gt;
** Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/32a7157a05370f95ff11109eda9c7512c07390a8 Handle any address length in DUID]&lt;br /&gt;
* The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:&lt;br /&gt;
**[https://gitlab.com/kavbhat/ns-3-dev/-/commit/e9ba9ec3f521e8f26fa2c53522829cd301d87277 Code cleanup]&lt;br /&gt;
* Initial documentation has been added for the DHCPv6 application. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/22ed8e5f7287d8861d5b1c9d44b1c7473f4f764b Documentation outline]&lt;br /&gt;
&lt;br /&gt;
=== Week 9 ===&lt;br /&gt;
'''Duration: ''' July 22 - July 28&lt;br /&gt;
* Corrected the usage of IAIDs in IA_NA options based on [https://datatracker.ietf.org/doc/html/rfc8415#section-12 Section 12 of RFC 8415]. Each interface on a client uses a single IA_NA with a unique IAID.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/78592d5401eee1c1a35ec3a23ea270843fe6be28 IAID corrections]&lt;br /&gt;
* Changed the periodic Solicit message to use a TrickleTimer, such that the frequency of messages gradually decreases. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/9df2c2047429fda1a0957ed04df1b5b04b4b58af TrickleTimer for Solicits].&lt;br /&gt;
* Added further documentation for DHCPv6: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/77f512a27e4421174374266791b705b19e2a71c5 Update documentation]&lt;br /&gt;
&lt;br /&gt;
=== Week 10 ===&lt;br /&gt;
'''Duration: ''' July 29 - August 4&lt;br /&gt;
* Improved the code for cleaning up leases periodically and updating lease bindings. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/3ccdb3a5a3aa9975adc2cf2b9deb1bfdd1a33662 Code cleanup]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2be995514fc4e98ff39d718c723a3fb59d634f9 Add client DUID in ExpiredAddresses]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0f195c70623fe080ce64979b8156fe95c677669e Separate DUID class]&lt;br /&gt;
* Opened a draft [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 MR] for stateful DHCPv6.&lt;br /&gt;
&lt;br /&gt;
=== Week 11 ===&lt;br /&gt;
'''Duration: ''' August 5 - August 11&lt;br /&gt;
* Modified the class for DUID.&lt;br /&gt;
** The aim was to use a general byte array, instead of remaining confined to the ''Address'' type.&lt;br /&gt;
** 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).&lt;br /&gt;
** The class has also been moved to new files, namely ''dhcp6-duid.h'' and ''dhcp6-duid.cc''.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/be3aa7545d2a8b2b54e964b6cd73c46bdbfb03fe Modified DUID class]&lt;br /&gt;
* ''IdentifierOptions'' earlier used a smart pointer to the DUID (''Ptr&amp;lt;Duid&amp;gt;''). The code has been modified to use a object of type ''Duid'' instead.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13249</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13249"/>
		<updated>2024-08-07T19:33:02Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;br /&gt;
&lt;br /&gt;
=== Week 8 ===&lt;br /&gt;
'''Duration: ''' July 15 - July 21&lt;br /&gt;
* Refactored the code for Decline messages and accepting the address offer. The client now uses the ''DadFailure'' and ''DadSuccess'' callbacks. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/912e0147f9a1d5c5067faa4176f82d58e2d90c71 Use DAD callbacks]&lt;br /&gt;
* 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. &lt;br /&gt;
** Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/32a7157a05370f95ff11109eda9c7512c07390a8 Handle any address length in DUID]&lt;br /&gt;
* The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:&lt;br /&gt;
**[https://gitlab.com/kavbhat/ns-3-dev/-/commit/e9ba9ec3f521e8f26fa2c53522829cd301d87277 Code cleanup]&lt;br /&gt;
* Initial documentation has been added for the DHCPv6 application. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/22ed8e5f7287d8861d5b1c9d44b1c7473f4f764b Documentation outline]&lt;br /&gt;
&lt;br /&gt;
=== Week 9 ===&lt;br /&gt;
'''Duration: ''' July 22 - July 28&lt;br /&gt;
* Corrected the usage of IAIDs in IA_NA options based on [https://datatracker.ietf.org/doc/html/rfc8415#section-12 Section 12 of RFC 8415]. Each interface on a client uses a single IA_NA with a unique IAID.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/78592d5401eee1c1a35ec3a23ea270843fe6be28 IAID corrections]&lt;br /&gt;
* Changed the periodic Solicit message to use a TrickleTimer, such that the frequency of messages gradually decreases. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/9df2c2047429fda1a0957ed04df1b5b04b4b58af TrickleTimer for Solicits].&lt;br /&gt;
* Added further documentation for DHCPv6: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/77f512a27e4421174374266791b705b19e2a71c5 Update documentation]&lt;br /&gt;
&lt;br /&gt;
=== Week 10 ===&lt;br /&gt;
'''Duration: ''' July 29 - August 4&lt;br /&gt;
* Improved the code for cleaning up leases periodically and updating lease bindings. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/3ccdb3a5a3aa9975adc2cf2b9deb1bfdd1a33662 Code cleanup]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2be995514fc4e98ff39d718c723a3fb59d634f9 Add client DUID in ExpiredAddresses]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0f195c70623fe080ce64979b8156fe95c677669e Separate DUID class]&lt;br /&gt;
* Opened a draft [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2084 MR] for stateful DHCPv6.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13246</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13246"/>
		<updated>2024-07-30T22:38:03Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;br /&gt;
&lt;br /&gt;
=== Week 8 ===&lt;br /&gt;
'''Duration: ''' July 15 - July 21&lt;br /&gt;
* Refactored the code for Decline messages and accepting the address offer. The client now uses the ''DadFailure'' and ''DadSuccess'' callbacks. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/912e0147f9a1d5c5067faa4176f82d58e2d90c71 Use DAD callbacks]&lt;br /&gt;
* 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. &lt;br /&gt;
** Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/32a7157a05370f95ff11109eda9c7512c07390a8 Handle any address length in DUID]&lt;br /&gt;
* The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:&lt;br /&gt;
**[https://gitlab.com/kavbhat/ns-3-dev/-/commit/e9ba9ec3f521e8f26fa2c53522829cd301d87277 Code cleanup]&lt;br /&gt;
* Initial documentation has been added for the DHCPv6 application. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/22ed8e5f7287d8861d5b1c9d44b1c7473f4f764b Documentation outline]&lt;br /&gt;
&lt;br /&gt;
=== Week 9 ===&lt;br /&gt;
'''Duration: ''' July 22 - July 28&lt;br /&gt;
* Corrected the usage of IAIDs in IA_NA options based on [https://datatracker.ietf.org/doc/html/rfc8415#section-12 Section 12 of RFC 8415]. Each interface on a client uses a single IA_NA with a unique IAID.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/78592d5401eee1c1a35ec3a23ea270843fe6be28 IAID corrections]&lt;br /&gt;
* Changed the periodic Solicit message to use a TrickleTimer, such that the frequency of messages gradually decreases. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/9df2c2047429fda1a0957ed04df1b5b04b4b58af TrickleTimer for Solicits].&lt;br /&gt;
* Added further documentation for DHCPv6: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/77f512a27e4421174374266791b705b19e2a71c5 Update documentation]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13238</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13238"/>
		<updated>2024-07-23T13:38:03Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;br /&gt;
&lt;br /&gt;
=== Week 8 ===&lt;br /&gt;
'''Duration: ''' July 15 - July 21&lt;br /&gt;
* Refactored the code for Decline messages and accepting the address offer. The client now uses the ''DadFailure'' and ''DadSuccess'' callbacks. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/912e0147f9a1d5c5067faa4176f82d58e2d90c71 Use DAD callbacks]&lt;br /&gt;
* 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. &lt;br /&gt;
** Correction to be made: The code still makes an (incorrect) assumption that an 'invalid' link-layer address consists of all bytes being 'ff'.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/32a7157a05370f95ff11109eda9c7512c07390a8 Handle any address length in DUID]&lt;br /&gt;
* The client and server codes were cleaned up to use meaningful variable names and range-based for loops as necessary. Commits:&lt;br /&gt;
**[https://gitlab.com/kavbhat/ns-3-dev/-/commit/e9ba9ec3f521e8f26fa2c53522829cd301d87277 Code cleanup]&lt;br /&gt;
* Initial documentation has been added for the DHCPv6 application. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/22ed8e5f7287d8861d5b1c9d44b1c7473f4f764b Documentation outline]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13228</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13228"/>
		<updated>2024-07-16T14:22:48Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;br /&gt;
&lt;br /&gt;
=== Week 7 ===&lt;br /&gt;
'''Duration: ''' July 8 - July 14&lt;br /&gt;
* Modified the server to listen on all specified interfaces. This was done to align with [https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#dhcpv6-server-configuration DHCPv6 Kea], where all parameters are same across interfaces. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/e2802352bffaa0236565735443b80460b0bdc5eb Listen on multiple interfaces in DHCPv6 server]&lt;br /&gt;
* If a node has multiple interfaces, the DHCPv6 client on each interface ends up with a different DUID-LL. Fixed this mistake by scanning all the DHCPv6 applications installed on the client node, and looking for an existing DUID. Relevant commits:&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0879c224f0c1c65c62db9c1968d803f688505021 Select a NetDevice to set a common DUID-LL]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f821e585ac2eb184e9157de4f1f0494d98781feb Scan all applications to check if a valid DUID exists]&lt;br /&gt;
* Refactored the code to handle multiple IA options. Commit:  [https://gitlab.com/kavbhat/ns-3-dev/-/commit/68a26f24e6baf67245e4e3361907990697570f3f Handle multiple IA options.]&lt;br /&gt;
* Common Renew, Rebind events are to be scheduled across multiple IAs. Refactored the code for the same: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/de8f34c691b527dc5f66b31a8b756ff3251a233f Common Renew, Rebind events]&lt;br /&gt;
* Cleaned up code in the unit test. Currently, it uses 2 clients and 1 server, and asserts that the leased addresses are as expected. Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/c8731130c01b5a2f6cf14e29d84088c3e053e359 Unit test]&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2064 MR] to trace a valid address, determined after DAD completes and no duplicate address is found on the link.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13223</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13223"/>
		<updated>2024-07-09T06:55:36Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;br /&gt;
&lt;br /&gt;
=== Week 6 ===&lt;br /&gt;
'''Duration: ''' July 1 - July 7&lt;br /&gt;
* Created a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2053 MR] to add a TracedCallback to ''Icmpv6L4Protocol'', to return the invalidated address when DAD fails. &lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/684da96920b2a78dbdaa9d62f071a01a2766a7d3 Release event, lease clean-up event]&lt;br /&gt;
** 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.&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d088690b6827e7def1750dac93b400b98ffc7fe6 Perform DAD before accepting offered address]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/a44413ccdefcff4e3e868fe3a6e7daabe88c1047 Add status code option, handle Decline message]&lt;br /&gt;
* 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: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/246806aa8d5abae07f563cad2064375710cae636 Validate status codes in Reply].&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13213</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13213"/>
		<updated>2024-07-02T11:57:22Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;br /&gt;
&lt;br /&gt;
=== Week 5 ===&lt;br /&gt;
'''Duration: ''' June 24 - June 30&lt;br /&gt;
* Added the Option Request option, for the client to request the SOL_MAX_RT option from the server.&lt;br /&gt;
* Added a Renew event for the client to renew (and extend the lifetime of) the leased address. &lt;br /&gt;
* Had earlier added the IAID initialization in the server. Fixed this to ensure that the client decides the IAID value(s).&lt;br /&gt;
* Added a Rebind event to the client, which is triggered only if the Renew / Reply message exchange does not take place.&lt;br /&gt;
* Commits: &lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/ab5c363e1bf217bc28c6458cee9c62b4fddfc2f1 Add ORO, SOL_MAX_RT options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/61847a98cbff05846980563d97ea1fe392eb7422 Add Renew event, Fix IAID usage]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/725a82b35fa1bbe2351810206350d245718249fc Add Rebind event]&lt;br /&gt;
* Changes to be made:&lt;br /&gt;
** 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.&lt;br /&gt;
** Clean-up of expired leases: Change lease information status from &amp;quot;active&amp;quot; to &amp;quot;expired&amp;quot; with a periodic cleanup event. Scheduling an expiration event for each address will cause the queue to build up.&lt;br /&gt;
** Test working of application with multiple clients sending requests to a single server.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13206</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13206"/>
		<updated>2024-06-25T06:11:51Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;br /&gt;
&lt;br /&gt;
=== Week 4 ===&lt;br /&gt;
'''Duration: ''' June 17 - June 23&lt;br /&gt;
* Refactored the server to store lease information in a separate class. Each object of this class would contain:&lt;br /&gt;
** Subnet information: Prefix, Range of addresses.&lt;br /&gt;
** Lease information: To track addresses leased from the subnet, client DUID, lease time.&lt;br /&gt;
** Expired addresses: To track addresses previously leased to a client on the network, now reclaimed by the server.&lt;br /&gt;
** 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?)&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/0408cf818536e60e4669c60ca81d1187adccd708 Refactored server]&lt;br /&gt;
* Fixed the method of leasing addresses from the server. New process followed is:&lt;br /&gt;
** Check if previously expired addresses are available. Offer an address from this list.&lt;br /&gt;
** Else, obtain the latest leased address (the last address from the ''LeasedAddresses'' list). Increment this address by 1, and offer it to the client. &lt;br /&gt;
*** 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/920dd730a384bc6cda6b31c069aae7a89a0d832f Fix leasing method, add periodic Solicit event]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13180</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13180"/>
		<updated>2024-06-18T04:20:02Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;br /&gt;
&lt;br /&gt;
=== Week 3 ===&lt;br /&gt;
'''Duration: ''' June 10 - June 16&lt;br /&gt;
* Added the ''Boot()'' method to the client for sending a Solicit message on starting the application, and a ''SendAdvertise()'' method to the server. &lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/b9fefb3273210a9bca8f85177fdd26a289e08217 Send and receive Solicit, Advertise messages]&lt;br /&gt;
* Modified the DHCPv6 helper and test case to allow users to define the required address pools.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/4ffa85f5ea7922a7e75ae5de35e7a65a87557894 DHCPv6 Helper, Test case]&lt;br /&gt;
* Added methods to the client and server handle Request / Reply message exchange to the client and server.&lt;br /&gt;
** 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.&lt;br /&gt;
** Client method ''AcceptReply()'' - reads the IA_NA option and corresponding IPv6 address, and then adds the offered address to the client.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/223bb7a8c5a5680a2262d1e499d281da73292f9c Request, Reply message exchange]&lt;br /&gt;
* Added an example for DHCPv6 in src/internet-apps/examples/&lt;br /&gt;
** 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.&lt;br /&gt;
** Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/d84f9ee721ba756d65c708b750e47e01821b5983 DHCPv6 example]&lt;br /&gt;
* 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.&lt;br /&gt;
* To-do for upcoming week: &lt;br /&gt;
** Design the class for storing lease information, and refactor DHCPv6 server accordingly.&lt;br /&gt;
** Configure the renew and rebind timers for the client to begin the address renewal and rebind procedures.&lt;br /&gt;
** Add the (mandatory) OptionRequest option, and try to ensure that all four messages are compliant with the rules in the RFC.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13161</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13161"/>
		<updated>2024-06-10T13:25:54Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;br /&gt;
&lt;br /&gt;
=== Week 2 ===&lt;br /&gt;
'''Duration: ''' June 3 - June 9&lt;br /&gt;
* Implemented a minimal DHCPv6 client that:&lt;br /&gt;
** Binds a UDP socket to the specified NetDevice.&lt;br /&gt;
** Creates a packet with the Solicit message type, transaction ID, Elapsed Time option and sends it to the All Nodes multicast address.&lt;br /&gt;
* Implemented a minimal DHCPv6 server that:&lt;br /&gt;
** Binds a UDP socket to the All Nodes multicast address.&lt;br /&gt;
** On receiving a packet from the client, the server logs the information if the message type is SOLICIT.&lt;br /&gt;
* Implemented a DHCPv6 helper that:&lt;br /&gt;
** Installs the DHCPv6 client on a given set of nodes in a NodeContainer.&lt;br /&gt;
** Installs the DHCPv6 server on a specified node.&lt;br /&gt;
* Commits: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/f60025f9f0b6cc4a337b0f878e183a558f7b464a Minimal DHCPv6 client and server]&lt;br /&gt;
* To be done:&lt;br /&gt;
** 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.&lt;br /&gt;
** Specify the interface that the DHCPv6 server should listen on. User may specify a Ptr&amp;lt;NetDevice&amp;gt; for the same.&lt;br /&gt;
** (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.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13160</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13160"/>
		<updated>2024-06-09T12:34:00Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Week 1 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options. (Note: Planning not to implement DHCPv6 relay for now.)&lt;br /&gt;
** Doubt: How do we verify that the hardware type in the DUID is valid according to the standard [https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml IANA Hardware types]? &lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Considerations for client and server implementations:&lt;br /&gt;
** Configure the rebind / renew timers carefully.&lt;br /&gt;
** Client state (waiting for address lease, configuring the refresh state) will need to be maintained.&lt;br /&gt;
* Commits: Implemented following sections of [https://datatracker.ietf.org/doc/html/rfc8415#section-21 RFC 8415 options].&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/381f4c8ac2d1f43fbf4b504886ef56f0078629af Identifier Options, Elapsed time options]&lt;br /&gt;
** [https://gitlab.com/kavbhat/ns-3-dev/-/commit/430b812013ab798256807248fa867f4216c66fc8 IANA, IATA, IA Address options]&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13159</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13159"/>
		<updated>2024-06-09T12:21:15Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Community Bonding Period */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
** DUID format to be used for the Client / Server Identifiers: [https://datatracker.ietf.org/doc/html/rfc8415#section-11.4 DUID based on Link-Layer address]&lt;br /&gt;
* Testing the DHCPv6 application and message exchanges:&lt;br /&gt;
** Before starting the client and server applications, test DHCPv6 header serialization and deserialization.&lt;br /&gt;
** Test stateful DHCPv6 (four message exchange) between the client and server.&lt;br /&gt;
** Test stateless DHCPv6 (Information-Request / Reply messages).&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Put each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
* Commit: [https://gitlab.com/kavbhat/ns-3-dev/-/commit/cfa3c24d79178c2fcc5d0bb358bc7a0dcc266f5a Classes for header and options]&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options.&lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Began discussions on client and server implementations.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13158</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13158"/>
		<updated>2024-06-09T12:11:43Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Community Bonding Period */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and discussed some of the considerations:&lt;br /&gt;
** Can a DHCPv6 server hand out addresses that are not announced by the router in the PIO? [https://datatracker.ietf.org/doc/html/rfc8415#section-18 Section 18 of RFC 8415] suggests that DHCPv6 clients may operate independently, even when RAs are not received.&lt;br /&gt;
** Do we need to prevent SLAAC on global addresses? [https://blogs.infoblox.com/ipv6-coe/slaac-to-basics-part-2-of-2-configuring-slaac/ Infoblox Blog] mentions that we can have SLAAC and DHCPv6 operating at the same time. (Future work: prevent or handle address collisions.)&lt;br /&gt;
** Ensuring that routers use the correct flag in the RA.&lt;br /&gt;
* Discussed the approach to testing the DHCPv6 messages and application.&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations for the message type and transaction ID.&lt;br /&gt;
* Made each DHCPv6 option a separate class. Combined similar options (such as Client Identifer / Server Identifier options) into the same class, to prevent redundancy.&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options.&lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Began discussions on client and server implementations.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13150</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13150"/>
		<updated>2024-06-02T13:32:40Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Weekly Reports */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and potential issues with the proposal ideas.&lt;br /&gt;
* Discussed the approach to testing the DHCPv6 messages and application.&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations.&lt;br /&gt;
* Modified the approach for DHCPv6 Options, to allow for modularization and reduction of code redundancy.&lt;br /&gt;
&lt;br /&gt;
=== Week 1 ===&lt;br /&gt;
'''Duration: ''' May 27 - June 2&lt;br /&gt;
* Added getter/setter methods for (currently) relevant DHCPv6 options.&lt;br /&gt;
* Implemented member methods to add options to the DHCPv6 header.&lt;br /&gt;
* Tested header serialization and deserialization to ensure options are added correctly (sanity test!).&lt;br /&gt;
* Began discussions on client and server implementations.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13134</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13134"/>
		<updated>2024-05-27T17:15:43Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;br /&gt;
&lt;br /&gt;
= Weekly Reports =&lt;br /&gt;
=== Community Bonding Period ===&lt;br /&gt;
'''Duration: ''' May 1 to May 26&lt;br /&gt;
* Worked on the [https://docs.google.com/document/d/16lEXgDg6alcw8zgUzSgy9PIfCapPlILvdx0iBXCdivQ/edit?usp=sharing design document], and potential issues with the proposal ideas.&lt;br /&gt;
* Discussed the approach to testing the DHCPv6 messages and application.&lt;br /&gt;
* Created the class for the DHCPv6 header and added the getter/setter implementations.&lt;br /&gt;
* Modified the approach for DHCPv6 Options, to allow for modularization and reduction of code redundancy.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13105</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13105"/>
		<updated>2024-05-04T02:51:24Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Milestones */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
=== Phase 1 ===&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
=== Phase 2 ===&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
=== Phase 3 ===&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13104</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13104"/>
		<updated>2024-05-04T02:49:49Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Milestones */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;br /&gt;
The GSoC period is divided into three phases. According to the proposal, the deliverables are as follows:&lt;br /&gt;
&lt;br /&gt;
== Phase 1 ==&lt;br /&gt;
'''Duration: ''' Week 1 to Week 6&lt;br /&gt;
* Create the Dhcp6Header class and add the member function implementations.&lt;br /&gt;
* Create the Dhcp6Server class and add the necessary functionality.&lt;br /&gt;
* Create the Dhcp6Client class and implement the member functions for requesting and binding addresses.&lt;br /&gt;
* Write unit tests for the new classes.&lt;br /&gt;
&lt;br /&gt;
== Phase 2 ==&lt;br /&gt;
'''Duration: ''' Week 7 to Week 10&lt;br /&gt;
* Extend the implementation to support additional options in DHCPv6.&lt;br /&gt;
* Work on the tests and examples for the new application model.&lt;br /&gt;
&lt;br /&gt;
== Phase 3 ==&lt;br /&gt;
'''Duration: ''' Week 11 to Week 12&lt;br /&gt;
* Fix any failing tests, and add additional tests as required.&lt;br /&gt;
* Add documentation for the DHCPv6 model.&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13103</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13103"/>
		<updated>2024-05-04T02:32:53Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Project Proposal:''' [https://drive.google.com/file/d/1PjWxKP3Tydh9jTVjiTQ8Pphp16EaDT-9/view?usp=sharing Link]&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
	<entry>
		<id>https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13102</id>
		<title>GSOC2024DHCPv6</title>
		<link rel="alternate" type="text/html" href="https://www.nsnam.org/mediawiki/index.php?title=GSOC2024DHCPv6&amp;diff=13102"/>
		<updated>2024-05-04T02:09:06Z</updated>

		<summary type="html">&lt;p&gt;Kavyabhat: /* Project Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{TOC}}&lt;br /&gt;
&lt;br /&gt;
Back to [[Summer_Projects#Google_Summer_of_Code_2024 | GSoC 2024 projects]]&lt;br /&gt;
&lt;br /&gt;
= Project Overview =&lt;br /&gt;
&lt;br /&gt;
* '''Project Name:''' DHCPv6&lt;br /&gt;
* '''Student:''' Kavya Bhat&lt;br /&gt;
* '''Mentors:''' Tommaso Pecorella, Alberto Gallegos Ramonet, Manoj Kumar Rana&lt;br /&gt;
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2024/projects/X6Wbehcn &lt;br /&gt;
* '''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.&lt;br /&gt;
* '''Repository:''' https://gitlab.com/kavbhat/ns-3-dev/-/tree/gsoc-24 &lt;br /&gt;
* '''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.&lt;br /&gt;
&lt;br /&gt;
= Milestones =&lt;/div&gt;</summary>
		<author><name>Kavyabhat</name></author>
	</entry>
</feed>