Index | Thread | Search

From:
Renaud Allard <renaud@allard.it>
Subject:
Re: [new] net/neighbot 0.3.0
To:
Matthieu Herrb <matthieu@herrb.eu>
Cc:
ports@openbsd.org
Date:
Tue, 24 Feb 2026 18:48:56 +0100

Download raw body.

Thread

On 24/02/2026 17:18, Matthieu Herrb wrote:
> Thanks for the reactivity.  with 0.3.3, I still have some 'moved' alerts from
> an IPv6 routable address to a Link Local one, and some 'moved' alerts
> from an IPv4 routable address to a IPv6 Link Local one.
> 
> Also for one misconfigured machine which uses temporary IPv6 addresses
> I got 'new station' messages for each new temporary address. I don't
> know if this is by design or not. Our policy is to forbid this
> kind of obfuscation on that network segment, so I'd rather get a
> 'moved' notification in this case.
> 

Try out 0.3.5.
Here are the scenarii I thought for it.

   Scenario 1: SLAAC address appears first 
  

   - MAC M seen at 2001:db8::a8bb:ccff:fedd:eeff (EUI-64 derived) 
  

   - temp_rotate: is_eui64() returns true -> temp_rotate = 0 
  

   - Result: "new station" + email. Correct. 
  

  
  

   Scenario 2: First temporary address in same /64 
  

   - MAC M already has SLAAC 2001:db8::eui64 in DB 
  

   - MAC M seen at 2001:db8::rand1 (not EUI-64) 
  

   - temp_rotate: not link-local, not EUI-64, calls 
db_has_temp_in_prefix(M, 2001:db8::rand1) 

   - DB scan: finds 2001:db8::eui64 -> same /64, not same IP, not 
link-local, IS EUI-64 -> skipped 

   - No non-EUI-64 match -> returns 0 -> temp_rotate = 0 
  

   - Result: "new station" + email. Correct (first temporary). 
  

  
  

   Scenario 3: Second temporary address (rotation) 
  

   - MAC M has SLAAC 2001:db8::eui64 and temp 2001:db8::rand1 in DB 
  

   - MAC M seen at 2001:db8::rand2 (not EUI-64) 
  

   - db_has_temp_in_prefix: finds 2001:db8::eui64 -> EUI-64 -> skipped. 
Finds 2001:db8::rand1 -> same /64, not same IP, not link-local, not 
EUI-64 -> returns 1
   - temp_rotate = 1 

   - Result: "new temporary" (log only, no email). Probes scheduled for 
old IPs -> old temp times out -> "moved" email. Correct. 

  
  

   Scenario 4: Regular IPv4 new station 
  

   - af == AF_INET -> temp_rotate = 0 
  

   - Result: normal "new station". No regression. 
  

  
  

   Scenario 5: Regular IPv6 new station (different /64) 
  

   - MAC M has 2001:db8:1::rand1 in DB 
  

   - MAC M seen at 2001:db8:2::rand2 (different /64) 
  

   - db_has_temp_in_prefix: prefix 2001:db8:2 doesn't match 2001:db8:1 
-> returns 0 

   - Result: "new station" + email. Correct. 
  

  
  

   Scenario 6: Link-local IPv6 
  

   - ip[0] == 0xfe && (ip[1] & 0xc0) == 0x80 -> temp_rotate = 0 
  

   - Result: normal "new station" (link-local probing already suppressed 
separately). No regression.