Opened 8 years ago

Last modified 3 years ago

#8316 assigned enhancement

Haiku needs IPv6 link scope Auto Configuration

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Network & Internet/IPv6 Version: R1/Development
Keywords: local scope Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by kallisti5)

Haiku needs to generate a link scope address on all interfaces when the ipv6 module is present.

Here is an example from Linux:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 14:da:e9:51:54:22 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.162/24 brd 10.10.10.255 scope global eth0
    inet6 fe80::16da:e9ff:fe51:5422/64 scope link valid_lft forever preferred_lft forever

Attachments (1)

ipv6localLink.diff (10.9 KB ) - added by kallisti5 8 years ago.
v1.0

Download all attachments as: .zip

Change History (19)

comment:1 by kallisti5, 8 years ago

Description: modified (diff)

comment:2 by kallisti5, 8 years ago

ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt

Implementation notes:

IPv6 link scope addresses are based on the MAC address of the card.

Once we have the local link address, we must then perform an ICMPv6 ping to ensure it's available. (Duplicate Address Detection (DAD))

You can find more plain-english descriptions here: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html

comment:3 by axeld, 8 years ago

Most of this should already be implemented, see http://cgit.haiku-os.org/haiku/tree/src/servers/net/AutoconfigLooper.cpp#n123 and following.

comment:4 by kallisti5, 8 years ago

Wasn't aware that was implemented.. nice job.

All that code depends on INET6 being defined... however grepping through the Haiku tree doesn't result in any spots we define INET6. Is this on purpose?

comment:5 by axeld, 8 years ago

I assume that Atis didn't want to break existing code for his in-progress work on IPv6. Since no one had the time to work on IPv6 in the mean time, no one bothered to remove those defines (I don't think it makes much sense to make that optional; the headers are always there, anyway).

comment:6 by kallisti5, 8 years ago

Ahh..

It's commented out in the net server jam file:

http://cgit.haiku-os.org/haiku/tree/src/servers/net/Jamfile#n13

Also, while the rest of the checks are #ifdef INET6, the following is a plain if...

http://cgit.haiku-os.org/haiku/tree/src/servers/net/NetServer.cpp#n108

comment:7 by kallisti5, 8 years ago

Let me go ahead and remove those #ifdef's as well as the commented out define in the Jamfile.

I'll give it a quick compile and see if we get a stable local ipv6 address... If so committing them out and closing this issue sounds like a resolution to me.

I'll give you an hour before making any changes upstream in case you have other plans. I don't wanna step on your toes.

comment:8 by axeld, 8 years ago

Huh? I have a hard time remembering my last commit ;-) Please just go ahead, if you have the time to test it, my toes certainly don't mind.

comment:9 by kallisti5, 8 years ago

Jeesh.

This change turned from a little fix to a rewrite *real* quick.

Attaching the work I have so far...

This *almost* works, however I am still getting a strange IPv6 address.

I moved the ConfigLinkLocal call to NetServer from the looper... It seemed like a bad place for LinkLocal. (as the looper is only called on autoconfig == true)

always setting up a linklocal address is a good idea because it's not your primary ipv6 address. (ipv6 router advertisement or DHCPv6 would be a good fit for the looper however)

by kallisti5, 8 years ago

Attachment: ipv6localLink.diff added

v1.0

comment:10 by kallisti5, 8 years ago

Has a Patch: set

comment:11 by kallisti5, 8 years ago

committed a much different solution in hrev43721 :)

I think we need to add a few routes as well.. but I have *no* idea what their source + destination should be.

At the moment pinging ::1 doesn't even work though... so testing the actual connectivity is hard.

comment:12 by axeld, 8 years ago

That used to work at some point, though. Dunno what is going wrong now. Does the loopback interface have an IPv6 address?

Last edited 8 years ago by axeld (previous) (diff)

comment:13 by kallisti5, 8 years ago

Yeah, there is a ::1 address assigned to loopback with a strange prefix length:

inet6 addr: ::1, Prefix Length: 2147512363

there are 0 IPv6 routes though on the system... Maybe digging around would turn up a disabled route setup somewhere?

comment:14 by kallisti5, 8 years ago

My linux machine shows a prefix of 128.

Another question is address scope, it doesn't seem like we have have scope flags for each interface IP. (Scope: link (fe80::), Scope: host(::1), Scope: global(anything else))

The scope is probably the last todo.. we just have to worry about everything breaking when everyone starts using AAAA records.

comment:15 by kallisti5, 8 years ago

bah. that ::1 was a false positive. I was playing with the new network preflet a while back and I added it through that.

current systems don't spin up a loopback for ipv6.

I've dropped code into the network kit to add a loopback ::1, testing now.

comment:16 by luroh, 5 years ago

Milestone: R1Unscheduled

Moving IPv6 related tickets out of R1 milestone.

comment:17 by kallisti5, 3 years ago

Has a Patch: unset

comment:18 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.