I don't think anyone is particularly against the breaking of this (or that) v6 assumption, AS LONG AS the good Mikrotik guys would document and explain them EXTENSIVELY.
It is simply not fair to make these changes, completely fail to document them, wait until an user has issues and then (poorly and partially) explain the mechanism in a private reply to another user that raised the support question.
For all they know CGGXANNX could have kept these informations to himself.
Concur, if they want a vibrant beta testing experience, they should be providing beta documentation as well that we can peruse and tear apart and improve. Their beta effort is half assed. Its frustrating at times to see them spend so much on marketing and less on more practical endeavours.
Are you implying that Mikrotik communicated this change poorly? That just doesn't happen. Nope. Never.
More to the point: my comment was only related to the general nature of the change. As to how it's done and at what pace, everyone has their own preference. I would personally like to see it faster, in a rip off the band-aid style (with proper documentation, of course.) Navigating this type of change is never easy, additionally, as hard as it is to believe, I think Mikrotik is trying to be as backwards compatible as they can be. (With mixed results.)
@anav is also right of course. Some sort of roadmap would be very much appreciated. I can fully understand not wanting to commit to timelines, but something similar to what was done with the new routing engine could be used, where features to look forward to would at least be listed, and colored green when they become available.
The irony of course is that on one hand we have a company so invested in providing products that allow us to talk to each other and our devices, but on on the other hand is so lousy at communicating! ;-))
From the MikroTik response above:
The routing rule table will in the future list those implicit rules (shown is the current default order, as a result of a simple /routing/rule/print command) and will allow us to freely move (maybe disable too) them.
It looks like that in the current ROS 7 version, in your tests, when you don't use mangle rules, your routing rules are inserted somewhere between number #3 and #4. Which would explain why it worked. #0, #1 and #2 are not matched, but the local address is then matched by #3 before reaching your custom inserted rules.
It also explains how currently when none of our custom routing rules match, the default fallback action is to lookup in main.
The official documentation has been updated. Also mentions the new default routing rules that are not yet in the current beta or release versions.
From that page:
- exclude local from being marked by adding to mangle rule:
!dst-address-type=local
Shouldn't it be:
exclude local from being marked by adding to mangle rule:dst-address-type=!local
Better written as:
Replace this mangle rule:
/ip firewall mangle add in-interface=LAN action=mark-routing new-routing-mark=myTable
with this one:
/ip firewall mangle add in-interface=LAN dst-address-type=!local action=mark-routing new-routing-mark=myTable
which excludes local addresses.
Or the placement of the "!" is the same/works both ways?
Or is that the right syntax and mine above is wrong?
How is this different from rules been using for awhile??
Is my assumption that means ( dst-address-type=!local) connections to only other subnet gateways, aka interface gateways, or ONLY to other devices on other subnets, OR both???