• Tipoff and the IPv6 map

    From deon@1337:2/101 to MeaTLoTioN on Wednesday, July 08, 2026 08:51:11
    Howdy,

    Just discovered the IPv6 map, and I'd be really loving to see how I can get the value out of this. My goal is to get rid of IPv4 (it bugs me keeping two network stacks alive, and its twice the work when figuring out why something aint working - especially since not all devices prioritises IPv6 over IPv4).

    A thought, the map is rendering fd00:368:0:fe0a::/64 in my case, and below it is listing a handful of hosts, with their IPv4 address - I have to click on each one to see what it's IPv6 address is.

    I should have more IPv6 hosts, atleast all devices on the local lan should be getting one, but I'm only showing 10... :(

    Can you add the router as well? (From the RA announcements?)

    IPv6 is so much harder to know what the device is, especially since SLAAC gives it another 16 chars to the address, vs IPv4 DHCP that gives it 1 number...

    So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there is no need to re-show the first 16 chars again, perhaps just render it as *:a:b:c:d, or shortform *::23 when their is a vanity IPv6 address.

    (If you worked out a network was a /68, then you only need to show the last 15 chars, etc).

    Some of my hosts have both:

    fd00:368:0:fe0a:be24:11ff:fec8:9457
    fd00:368:0:fe0a::1:100

    I would show the "shorter one" (almost always vanity) over the larger one (almost always SLAAC).

    Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

    I could imagine if tipoff was really strong in helping understand the IPv6 network, it could become a key tool, since IPv6 is foreign to many and getting more pervasive every day.

    On that topic, an subnet calculator (IPv6/4) would be soo handy. I'm finding I'm always going to vultr to use theirs and having something local would nice :)

    I'm not getting many hostsnames either. Some proxmox machines are showing up with their number, others not, and the Intel ones are all the same version of proxmox. I must have messed something up there...

    Some hostnames are fully qualified, some just the "host" name. I need to figure out how to make those consistent as well.


    ...����
    --- SBBSecho 3.37-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)
  • From MeaTLoTioN@1337:1/101 to deon on Wednesday, July 08, 2026 13:48:34
    Howdy!

    Been a good few hours on the IPv6 front, thanks to your feedback.
    Went through your list properly

    I should have more IPv6 hosts, atleast all devices on the local lan
    should be getting one, but I'm only showing 10... :(

    The old approach only sent one multicast probe and read whatever was in the NDP cache a second later - anything slow to answer, asleep, or that just dropped the multicast (common on wifi) got missed. Now it probes three rounds a few seconds apart and keeps everything that answered across any of them.

    Can you add the router as well? (From the RA announcements?)

    Done - the router's address now comes straight from the kernel's own RA-learned route, so no guessing needed.

    is no need to re-show the first 16 chars again, perhaps just render it
    as *:a:b:c:d, or shortform *::23 when their is a vanity IPv6 address.

    Also done, and it renders exactly like you described - given the /64 is already shown on the segment header, each host card now just shows the host part, eg ::be24:11ff:fec8:9457 instead of the full address.

    Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

    Done, with one deliberate wording choice - I tagged it "EUI-64" rather than "SLAAC vs manual". Reason: privacy/temporary addresses (the default on Windows, macOS and iOS) aren't EUI-64 either, but they're not manually chosen, so calling everything-that-isnt-EUI-64 "manual" would be overclaiming. When a host has more than one address, the non-EUI-64 one shows as primary since it's usually the more intentional one, with the EUI-64 one tagged and secondary.

    So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there

    Added a "Show IPv6 first" toggle on the map - stays IPv4 by default for everyone else, one click flips which family is the bold primary line for you.

    On that topic, an subnet calculator (IPv6/4) would be soo handy. I'm finding I'm always going to vultr to use theirs and having something
    local would nice :)

    Built one, entirely client side, no data leaves the browser. Handles both families, shows network/host range/address count, and for IPv6 tells you how many /64s a bigger block breaks down into.

    On top of all that, testing this properly on my own network turned up two real bugs your feedback didn't cause but the same push uncovered: the "derive the router/hosts' actual global address from its MAC" logic (added to plug the gap where NDP only reliably sees a neighbour's link-local address) wasnt finding the right route entry on a plain Debian/Ubuntu box, and the gateway card was hard-coded to hide link-local addresses even though a router's real address nearly always is link-local. Both fixed and confirmed working end to end - my own network went from a handful of IPv6 hosts showing to 25+ under the real /64 segment, router included.

    All of that is out now (v0.2.15 through v0.2.17). Keen to hear if it actually solves the "only 10 hosts" problem on your side too - your network's probably a better stress test than mine given how many IPv6-capable devices you're running.

    On the hostname front - separately fixed the FQDN vs short-name inconsistency too (DNS PTR lookups now get normalised to short name same as mDNS/NetBIOS already were), so that should tidy up too, though it only applies going forward - anything already scanned needs a rescan to pick up the fix.


    Cheers,
    Christian

    ---
    |14Best regards,
    |11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N // @meatlotion:erb.pw |10S|02SBBSS|08-|10M|08-|100|020001 |10C|02ertified |10B|02BS |10S|02YSOP

    |07�� |08[|10eml|08] |[email protected] |07�� |08[|10web|08] |15www.erb.pw |07��Ŀ |07�� |08[|09fsx|08] |1521:1/158 |07�� |08[|11tqw|08] |151337:1/101 |07���� |07�� |08[|12rtn|08] |1580:774/81 |07�� |08[|14fdn|08] |152:250/5 |07����
    |07�� |08[|10ark|08] |1510:104/2 |07��

    ... Top secret! Burn before reading!

    --- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
    * Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (1337:1/101)
  • From deon@1337:2/101 to MeaTLoTioN on Thursday, July 09, 2026 11:26:47
    Re: Re: Tipoff and the IPv6 map
    By: MeaTLoTioN to deon on Wed Jul 08 2026 01:48 pm

    Howdy,

    So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there

    Added a "Show IPv6 first" toggle on the map - stays IPv4 by default for everyone else, one click flips which family is the bold primary line for you.

    Nah, I'm not loving this ;) Well, I think it might be better a different way.

    So currently, you render the map showing IPv4 address for the IPv4 segement *and* the IPv6 segment.

    The toggle, when selected, shows IPv6 address for the IPv4 hosts that have one, and IPv4 otherwise. (I havent dont a full scan yet, so not sure if it's old data). The IPv6 segement shows the IPv6 address and the IPv4 below it.

    I like the toggle, but I think it would be better that:

    * When rendering the map, the IPv4 segement shows IPv4 addresses first, and the IPv6 segement shows the IPv6 addresses first.

    * The toggle flips it, so when selected, the IPv4 segment shows the hosts with an IPv6 address first, and the IPv6 segment shows the IPv4 address first.

    Why?

    * Currently, when I scroll all the way to the bottom of the page, I see that the IPv6 segment is showing IPv4 addresses (the current implementation), I have to scroll all the way to the top, to toggle it, and scroll all the way to the bottom to see the address.

    Yes, the address is there below the IPv4 address (smaller), but its an IPv6 segment, I dont necesarily want to focus to be on the IPv4 address.

    * The toggle helps me answer a question, when looking at the IPv4 segement, what's its IPv6 address? (And on the IPv6 segment, what's its IPv4 address?)

    * I guess ultimately, the toggle is cosmetic, because I know you show one address as a "title" and the other address as the "sub-title", so I would also be OK that the toggle button wasnt there at all.

    What also would be better, is a toggle to have the IPv6 segment at the top of the page (and that toggle to be remembered) - I'd find that very useful too. (Since I am now working in IPv6 first, and IPv4 is an after thought.)

    Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

    Done, with one deliberate wording choice - I tagged it "EUI-64" rather than "SLAAC vs manual".

    It might be good (if you havent dont it), to do the same with IPv4, ie: a segment address as allocated by a DHCP server or manual, vs an IPv4 address assigned automatically when there is no DHCP server present (cant remember what segment that is, 172.254.0.0/16?).

    (There will be a day that I turn off IPv4 DHCP completely :)


    ...����
    --- SBBSecho 3.37-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)
  • From deon@1337:2/101 to MeaTLoTioN on Thursday, July 09, 2026 11:29:26
    Re: Re: Tipoff and the IPv6 map
    By: MeaTLoTioN to deon on Wed Jul 08 2026 01:48 pm

    Howdy,

    Built one, entirely client side, no data leaves the browser. Handles both families, shows network/host range/address count, and for IPv6 tells you how many /64s a bigger block breaks down into.

    Forgot to mention, loving this.


    ...����
    --- SBBSecho 3.37-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)