[GSOC 2024] IPv6 finalization and stabilization [Updated Proposal Draft]

Community
1

[Update 1]
I am updating the scope and details of this project , taking @PulkoMandy suggestion into account .

  1. Implement Stateless Auto Address Configuration for ipv6 .
    This involves
    i) Implementing Duplicate Address Detection (#8319 (Haiku needs IPv6 Duplicate Address Detection) – Haiku)
    ii) Implementing Router Advertisement handling(#11862 (Net server multi-protocol rework) – Haiku) and sending Router Solicitation message .
    iii) Defining address scope flags for ipv6 → Link- Local, global

  2. Making address configuration independent for ipv4 and ipv6 → Currently , changing the address configuration mode for ipv4 or ipv6 through the networkstatus app or ifconfig command affects the settings of the other address family . This needs to be taken care of .(#7228 (RFC: BNetworkInterfaceAddress needs to store auto-configuration flags) – Haiku)

Questions

  1. #8319 (Haiku needs IPv6 Duplicate Address Detection) – Haiku - This ticket outlines the steps for duplicate address detection . The first and last step mentions about joining and leaving a well known MLDv2 multicast group . In Google, I did not find any article mentioning about these steps for Duplicate Address Detection . Hence my question is
    a) Why implementing these 2 steps are necessary ?
    b) What is the multicast address value of this well known multicast group in MLDv2 ?
    c) Does the joingroup function described here (Cross Reference: /haiku/src/add-ons/kernel/network/protocols/ipv6/ipv6.cpp) trying to achieve the joining into a multicast group ? I see no use of icmpv6 in this case .
    d) Same question as (c) for leavegroup function .(Cross Reference: /haiku/src/add-ons/kernel/network/protocols/ipv6/ipv6.cpp)

  2. The address scope flags for ipv6 (link local, global) needs to be stored at interface address level, is that correct ? Which means they need to be implemented in BNetworkInterfaceAddress class ?

  3. Should we introduce a separate flag to indicate ipv6 auto-config just like IFF_AUTO_CONFIGURED for ipv4 ? otherwise, NetServer should not set IFF_AUTO_CONFIGURED flag on the interface during ipv6 auto-configuration .

(Initial Post)
Hi everyone, I am looking forward to apply for GSOC 2024 under Haiku . I am interested to work on the project titled Ipv6 finalization and Stabilization (Duration 175 hours ). The project roughly covers the following topics

  1. #7228 - Separation of configuration settings for ipv4 and ipv6 .
    In the current codebase , if we try to auto-configure ipv4 through ifconfig or networkStatus GUI, it affects ipv6 and vice-versa .

  2. #8319 - Implementing Duplicate Address Detection
    Currently , there is no auto-configuration mechanism properly implemented for ipv6 , like DAD or DHCPv6 . The link local address generation is pre-existing but that needs to be coupled with DAD to make the ipv6 addressing fully functional, allowing us to access websites through ipv6 .

  3. #11862 - Making the netserver and AutoConfigLooper more generalised for different protocols instead of being ipv4 specific .
    The ticket highlights the following features to be functional :
    For ipv4, DHCP(already present) and 169.254.x.x based on MAC(already present)
    For ipv6 , router advertisement (to be taken care in DAD)
    The ticket also mentions about zeroconf for ipv4 and DHCPv6 for ipv6 but these two have not been emphasised in the ticket .

I have some questions regarding these topics

  1. Regarding point 3, should we be aiming to include both DHCPv6 and DAD in the project scope ?
  2. How should I go about testing the functionality for ipv6 ? My router probably doesn’t support ipv6 but I have no way of knowing for sure because it’s a public wifi router and I dont have access to the router’s webpage .
  3. Should zeroconf be taken care of as part of this project ?
8 Likes
2

It would be nice to have at least one way to assing IPv6 addresses automatically. DHCPv6, SLAAC, or something else. Otherwise, you will be limited in what you can test.

For testing, you need at least one other machine using IPv6 on the same network. If your network setup does not allow it, you should be able to set something up locally, using virtual machines.

Zeroconf is not required, especially if you do this as a 175 hours project. If you want to work longer, or if the other parts of the project turn out to be done very quickly, it can be added as an extended goal

3

Would request community feedback on the updated project scope details
@kallisti5 @waddlesplash @korli @PulkoMandy @scottmc @yaktest .

Thanks .

4

It is a bit confusing that you have edited the initial post and added more questions. When you do this, the forum does not send notifications to anyone (unlike when you do a new post), so I missed it.

Regarding #8319: The ticket does not mention where it got the info from, I think it is referring to RFC 4861: Neighbor Discovery for IP version 6 (IPv6) section 7.2.1. This links to RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 which defines the address, I think, in section 5.2.14:

Version 2 Multicast Listener Reports are sent with an IP destination
address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
routers listen.

The “join group” and “leave group” functions allow to join and leave a multicast group, that is, start and stop receiving messages that are sent to this group. The functions do not mention ICMP because that is unrelated. In this specific group, it happens that the messages received will be using the ICMP protocol, but in other multicast groups, it would be other protocols in the upper layers. The mutlicast handling functions don’t need to know anything about what the content of the packets will be, jst that you want to start or stop receiving them.

That seems correct to me.

IFF are flags for the network interface as a whole. I think in previous discussions we had decided that the notion of “auto configured” at the interface level did not make a lot of sense, instead, that is a notion that should be associated with an interface address. This means it could be stored at the same level as the link-local and global flags for IPv6 addresses. Net server will have to be adjusted to look into these address flags as needed, and not just at interface flags.

5

I am sharing a draft of my GSOC 2024 proposal

Request everyone to kindly provide their feedback on the same.
@kallisti5 @waddlesplash @korli @PulkoMandy @scottmc @yaktest .

2 Likes
7

You‘ve already tagged all of them 20hours ago!

You can‘t expect people will always respond within that timeframe for a hobby project, especially during a workday.

Please do not spam tags in this forum.

8

My apologies. I saw my post not being at the top and thought people might miss it .

9

No worries. the tagged people will have gotten a notification.

10

Yes, when you tag people they all get an email and things won’t be missed. But it may take a few days, especially at this time when several GSoC students are asking us to review their proposals and it’s a bit busier thna usual (in my case, combined with other things busier than usual in both my paid job and my personal life…).

11

I think your proposal is complete and includes the needed information, I don’t have any further comments to add. You can submit it to the GSoC website.

12

Thanks for your feedback .