上述所有的回答中，只有 @blessingsi 和 @JayZXu 的回答是正确的，其他的要么错误，要么没回答到点子上。

发包时会匹配路由表，而不是看是否和本机是否同一子网。假设你本地的路由表有很多条目，会拿目的地址与每一条路由条目匹配（实际存在二分查找），找到最长前缀那一条，再决定下一步的动作。

纠正上述一处错误：

在给 192.168.1.193 发送数据时，匹配到第 3 条路由，直接从“网卡 B”送出（目的 mac 地址为 192.168.1.193 的 mac 地址）。
在给 8.8.8.8 发送数据时，匹配到第 1 条路由，从“网卡 A ”经“网关 A”送出（目的 mac 地址为网关 A 的 mac 地址）。

> 计算机发送 ip 数据包时，如何判断目的 ip 和本地 ip 是否属于同一网段？
这个假设是错误的。发送 ip 数据包时，会通过查找路由表来决定发送的目的地，不会关心目的 ip 和本地 ip 是否属于同一网段。
实际上你本地计算机根本不知道目的 IP 的子网掩码，比如你往 8.8.8.8 发送数据，难道 Google 还需要暴露它的网络结构给你吗？

拿你的例子：
本地 ip：192.168.1.1 本地子网掩码：255.255.255.0
目的 ip：192.168.1.193 目的子网掩码：255.255.255.192

本机会生成路由表：
0.0.0.0/0 via 网关 A dev 网卡 A
local 192.168.1.1/32
192.168.1.0/24 dev 网卡 B

在给 192.168.1.193 发送数据时，匹配到第 3 条路由，直接从“网卡 A”送出（目的 mac 地址为 192.168.1.193 的 mac 地址）。
在给 8.8.8.8 发送数据时，匹配到第 1 条路由，从“网卡 B”经“网关 A”送出（目的 mac 地址为网关 A 的 mac 地址）。

不知道 OP 所使用的 ROS 具体版本和硬件是什么，可以试试给 MikroTik 提一 bug 让其对 Server DUID
的检查不要那么严格： https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1 。
或者我来代为提交 bug 也可以，不过 MikroTik 对个人用户提的 bug 响应时间很慢就是了。

尽量别开 web ，有被运营商请喝茶的可能。

先说结论，OP 所使用的当地运营商的 DHCPv6 服务器返回的消息格式存在 bug 。

按照 DHCPv6 的规范，服务器和客户端的 DUID 的组成格式为：2 个字节的 type code ，外加 1-128 字节可变长度的 identifier
（见 https://datatracker.ietf.org/doc/html/rfc8415#section-11 ）。

而 OP 给出的日志：
10:28:29 dhcp,debug,packet -> clientid: 00030001 0050568c 5e2f
10:28:29 dhcp,debug,packet -> serverid: 6660

客户端（ RouterOS ）的 DUID 是 00030001 0050568c 5e2f ，服务端的 DUID 是 6660 。
按照规范解读，客户端的 type code 是 0003 (DUID-LL)，hardware type 是 0001 ，后面的 0050568c 5e2f 是 link-layer 地址。
而服务端给的 DUID 是 6660 ，这只能解读为 type code 是 6660 （ RFC 中没有定义，应该是乱填的），然后没了。按照 RFC 的规定后面还要跟 1-128 字节的 identifier 。

所以结论就是，你的运营商的 DHCPv6 服务器响应的消息里 Server DUID 是乱填的（不知道谁开发服务器连 RFC 都不遵守），连长度都不对。RouterOS 报错且忽视了服务器的回应。

根本的解决方法是让运营商修服务器（可能性太低）或者换运营商。但我建议提出向 RouterOS 提一个 bug 吧，让 RouterOS 忽略这个错误就行了。

直接点申请退货，会退款并上门取件，其他不用你管。

一个典型的 SLAAC 分配地址的过程是：
1. 客户端向 ff02::2 组播地址发送 ICMP6 router solicitation 。所有支持 IPv6 的路由器都会监听这个组播地址。
2. 路由器向 ff02::1 组播地址发送 ICMP6, router advertisement ，包含前缀等信息。所有支持 IPv6 的任何设备都会监听这个组播地址。
3. 客户端拿前到前缀后，自己拼接一个 64 位的后缀，然后向一个特殊的组播地址（根据后缀利用哈希算法计算得出，自己也会监听这个地址）发送多次 ICMP6 neighbor solicitation 来检测地址冲突。
4. 如果没有其他设备回应，则表示这地地址没有被使用，则客户端使用这个地址。

@zbinlin RFC 4443: https://www.rfc-editor.org/rfc/rfc4443#section-2.1
Every ICMPv6 message is preceded by an IPv6 header and zero or more
IPv6 extension headers.

ICMPv6 消息外层是 IPv6 头，所以三层隧道上是可以路 ICMPv6 的。ping 也是基于 ICMPv6 ，二层不能跨路由器，而你可以 Ping 全球任何一个地址。

@baobao1270
@shenyuzhi
@zbinlin

SLAAC 基于 ICMPv6 ，是跑在三层之上的。理论上可以在 wireguard 上跑（如果配置好 link-local 地址并且接受相应的组播地址的话），但没有现成的实现。

@fox233 1452 是 ipv4 的，ipv6 不能超过 1432 。MTU 更小一些也可以，不过理论上因为传输效率低了网速要慢一点点。

@goodokgood1 不清楚梅林，但只要固件提供这个功能都可以试试。

要我说，能埋就埋，光纤便宜的很

这就是为什么很多相机用的 SD 卡那么贵的原因，写入速度高啊。我手中的 UHS-i 卡写入大概 80-90 MB/s 。

Pixel 7 ，亚马逊海淘才 3000 来块

被你带偏了，应该是 ping -M do -s <size> <IP>

你的测法是错的。正确方法是 ping -M do -l <size> <IP>，然后给 size 加上 28 。

第一个问题，关闭 DHCPv6 ，使用 SLAAC 即可解决

org 在使用范围上没有限制，只是给人的感觉是非营利性的。