A little bit of context: AAAA is my laptop and BBBB is my phone which is currently sleeping. BBBB is not pingable nor it appears /ipv6/neighbors. An app on AAAA cached BBBB-IPv6 and continuously tries to reach BBBB.
This is what I see in the IPv6 firewall filter:
... firewall,info ... forward: in:vlan-main out:lo, connection-state:new src-mac AAAA-MAC, proto UDP, [AAAA-IPv6]:3722->[BBBB-IPv6]:3722, len 12
... firewall,info ... forward: in:lo out:lo, connection-state:new proto UDP, [AAAA-IPv6]:3722->[BBBB-IPv6]:3722, len 12
Note that the second record lacks src-mac. Both logged rules are configured with action=reject reject-with=icmp-admin-prohibited.
Why do the unroutable packets even hit the forward chain? I don’t recall this behavior in the past.
In my deployment I implement NPTv6 to let IPsec clients with ULA addresses to access internet using a GUA derived from an upstream delegated IPv6 prefix:
I “reserve” and IPv6 prefix by allocating a non-advertising address on the lo loopback interface: /ipv6/address/add advertise=no from-pool=global interface=lo
I use the reserved prefix to mangle IPSEC ↔ WAN packets via the IPv6 firewall mangle snpt / dnpt rules
Since RouterOS lacks support for enforcing a Subnet ID for from-pool addresses the assignment is arbitrary and what was the vlan-main prefix may become the lo prefix next time the DHCPv6 Client’s script is run. This explains why and how the vlan-main hosts got the address from the lo prefix.
I still not quite sure why my laptop uses the deprecated address to reach my phone, I will look into that separately. Still, I think the RouterOS is in the wrong here with respect to the behavior of IPv6 firewall filter.
Note that some releases ago, when people with dynamic IPv6 addresses complained about old addresses not being deprecated, some logic was added to RouterOS to handle this case.
I think it is buggy. E.g. on current releases, when you assign an address to an interface and then disable it, it will still announce it indefinately as “deprecated”, not only for the lifetime of the announcement. It will do that until a reboot.
Maybe your problem is somehow related to that. See if a reboot makes it stop doing this.
Thanks to the SMB bug my ax3 crashes and gets rebooted a few times a day
I think the deprecation in my case is working properly: when prefix gets reassigned to another interface it seems correct to mark as deprecates on the old one. But it is wrong that Subnet ID is neither stable nor under administrative control.
I agree it would be much better when you could specify a subnet hint for “from pool”.
But the “deprecated” thing is an issue because some old or broken network stacks, like the one in WinPE, do not recognize it and they put the deprecated address on the interface anyway (and start using it).
It would be much better when the “announce as deprecated” feature would last only for the “valid lifetime” of the annoucement… and then just stops being announced.
Then how would you expect the client OS to select source address among multiple prefixes in standard compliant way? It’d seem to me that misbehaving clients should rather have a static LUA with a translator in front of them. Not great and not standard but a better workaround IMO.
I never checked, but does RouterOS renew validity interval when it advertises prefix as deprecated? Does it advertise it beyond the validity interval?
RouterOS still advertises a deprecated prefix 2 months after it has been deprecated… it never stops unless you reboot.
Normally I am not an advocate of working around other people’s bugs, but in this case it can be claimed that at least other people’s bugs would not be triggered when the own device would behave a bit more reasonable.
There are other Windows bugs that can’t be worked around, like the problem of a Windows device connected to a hybrid LAN port with both untagged traffic (that is to be recognized by the device) and VLAN tagged traffic (that is to be ignored).
This is common on a switchport that has both an IP phone and a computer (connected via a switch in the phone).
When IPv6 RA is running on the tagged VLAN, Windows will listen to the RA and put an invalid IPv6 prefix on the interface, thus causing unexplainable delays when using the computer… and it has been like that for a long time, without Microsoft doing anything about it.
Hmm, I don’t think I noticed this behavior. Then again I only ever have up to 2 prefixes simultaneously, so my hosts cannot get 1000 address. OTOH I’m with xfinity and my delegated prefix changes time to time.
What are your default settings for nd? Did you try the 7.16 beta release, as its notes mention a related change?
Your router crashes a few times per day so you would never notice this problem. I noticed it on a router that was up for several months, and where I experimented with different IPv6 setups (different addresses).
I tested it with a 7.15 beta and the problem was still there at that time.
