更换IP地址库以及增加对IPv6的支持？

[microka]

https://github.com/gaoyifan/china-operator-ip
https://gaoyifan.github.io/china-operator-ip/
对比了下，发现gaoyifan的IP地址库好像更加精细和更全，大佬能否增加一个对gaoyifan的适配呢？
以及能否增加对IPv6地址库的支持呢？感谢~

[larsonzh]

https://github.com/gaoyifan/china-operator-ip

https://gaoyifan.github.io/china-operator-ip/

对比了下，发现gaoyifan的IP地址库好像更加精细和更全，大佬能否增加一个对gaoyifan的适配呢？

以及能否增加对IPv6地址库的支持呢？感谢~

无意义，我OpenWrt接入两路支持IPv6的宽带，但只能使用一路IPv6，无法对IPv6流量分流，所以加入IPv6地址库，技术上没问题，应用上纯属多余，没任何用途。

与IPv4不同，当前的路由器系统无法对来自多个运营商的IPv6体系进行统一的控制管理，并将两个以上的IPv6地址下发给同一个内网设备。

[microka]

https://github.com/gaoyifan/china-operator-ip
https://gaoyifan.github.io/china-operator-ip/
对比了下，发现gaoyifan的IP地址库好像更加精细和更全，大佬能否增加一个对gaoyifan的适配呢？
以及能否增加对IPv6地址库的支持呢？感谢~

无意义，我OpenWrt接入两路支持IPv6的宽带，但只能使用一路IPv6，无法对IPv6流量分流，所以加入IPv6地址库，技术上没问题，应用上纯属多余，没任何用途。

与IPv4不同，当前的路由器系统无法对来自多个运营商的IPv6体系进行统一的控制管理，并将两个以上的IPv6地址下发给同一个内网设备。

我这边可以同时下发电信和移动的IPv6地址前缀给到内网设备（Windows），不过设备决定选择用哪个IPv6地址去访问互联网还不清楚能否由路由器进行参与控制。由于OpenWrt配置mwan太折腾，我暂时切回iKuai了 😂

[larsonzh]

本人 https://github.com/larsonzh/lzispro.git 项目专门用于生成各种所谓更加精细的 IPv4/6 运营商 IP 地址数据。

[larsonzh]

https://github.com/gaoyifan/china-operator-ip

https://gaoyifan.github.io/china-operator-ip/

对比了下，发现gaoyifan的IP地址库好像更加精细和更全，大佬能否增加一个对gaoyifan的适配呢？

以及能否增加对IPv6地址库的支持呢？感谢~

无意义，我OpenWrt接入两路支持IPv6的宽带，但只能使用一路IPv6，无法对IPv6流量分流，所以加入IPv6地址库，技术上没问题，应用上纯属多余，没任何用途。

与IPv4不同，当前的路由器系统无法对来自多个运营商的IPv6体系进行统一的控制管理，并将两个以上的IPv6地址下发给同一个内网设备。

我这边可以同时下发电信和移动的IPv6地址前缀给到内网设备（Windows），不过设备决定选择用哪个IPv6地址去访问互联网还不清楚能否由路由器进行参与控制。由于OpenWrt配置mwan太折腾，我暂时切回iKuai了 😂

电信的IPv6只能走电信通道，移动的IPv6只能走移动通道，体系不同，不能交叉。

如果内网设备可以获得不同运营商的多个IPv6地址，原理上是可以加入IPv6分流功能的。

[larsonzh]

项目软件采用的 IP 地址库源自 APNIC，内容准确、权威，全面覆盖中国所有 IPv4 地址，数据条目经过 CIDR 聚合压缩，在路由器内使用可获得极佳的经由效率，不需要更换新库。 36.206.32.1 地址位于铁通 crtc 库中的 36.192.0.0/11 网段地址中，无任何纰漏或错误。 您若对网络 IP 地址库生成感兴趣，可使用我另一开源项目（https://github.com/larsonzh/lzispro.git），自己在 OpenWrt 或其他 Linux 环境中生成地址库。该项目所设计的地址分类与 CIDR 聚合算法更为精准可靠。 LZ ---- 回复的原邮件 ---- ***@***.***>发送日期2024年10月18日 06:28 ***@***.***> ***@***.***>, ***@***.***>主题Re: [larsonzh/owmwpprt] 更换IP地址库以及增加对IPv6的支持？ (Issue #4) @larsonzh 作者您好，请问能否考虑增加 gaoyifan/china-operator-ip 这个地址库？比如 36.206.32.1 这个铁通地址，苍狼的移动和铁通地址库中都没包含该地址，而 https://gaoyifan.github.io/china-operator-ip/cmcc.txt 这里是有包含的。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[larsonzh]

这个 gaoyifan/china-operator-ip 地址库，似乎是把 cmcc 和 crtc 数据简单整合在一起，未进一步的做网段聚合压缩处理，故数据条目较多。 LZ ---- 回复的原邮件 ---- ***@***.***>发送日期2024年10月18日 06:28 ***@***.***> ***@***.***>, ***@***.***>主题Re: [larsonzh/owmwpprt] 更换IP地址库以及增加对IPv6的支持？ (Issue #4) @larsonzh 作者您好，请问能否考虑增加 gaoyifan/china-operator-ip 这个地址库？比如 36.206.32.1 这个铁通地址，苍狼的移动和铁通地址库中都没包含该地址，而 https://gaoyifan.github.io/china-operator-ip/cmcc.txt 这里是有包含的。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[microka]

@larsonzh 想请教一下 https://ispip.clang.cn/cmcc.html https://ispip.clang.cn/cmcc_cidr.html 前者和后者 CIDR 格式的有什么区别？实际包含的地址范围应该一致吧？为何要有两种不同的表述方式呢？CIDR 的更精简不是吗？

[larsonzh]

@larsonzh 想请教一下 https://ispip.clang.cn/cmcc.html https://ispip.clang.cn/cmcc_cidr.html 前者和后者 CIDR 格式的有什么区别？实际包含的地址范围应该一致吧？为何要有两种不同的表述方式呢？CIDR 的更精简不是吗？

前者是取自 APNIC 的原生 CIDR 地址条目，后者根据运营商分类对前者数据做了进一步的 CIDR 网段地址聚合的数据压缩，地址条目减少，数据更为精简和专业，可降低路由器资源占用，提高经由计算效率。两者地址范围一致，建议使用后者。

36.206.32.1 地址包含在 36.192.0.0/11 网段中：

[microka]

@larsonzh 想请教一下 https://ispip.clang.cn/cmcc.html https://ispip.clang.cn/cmcc_cidr.html 前者和后者 CIDR 格式的有什么区别？实际包含的地址范围应该一致吧？为何要有两种不同的表述方式呢？CIDR 的更精简不是吗？

前者是取自 APNIC 的原生 CIDR 地址条目，后者根据运营商分类对前者数据做了进一步的 CIDR 网段地址聚合的数据压缩，地址条目减少，数据更为精简，可降低路由器资源占用，提高经由计算效率。两者地址范围一致，建议使用后者。

学习了，感谢~

[byff]

https://github.com/gaoyifan/china-operator-ip

https://gaoyifan.github.io/china-operator-ip/

对比了下，发现gaoyifan的IP地址库好像更加精细和更全，大佬能否增加一个对gaoyifan的适配呢？

以及能否增加对IPv6地址库的支持呢？感谢~

无意义，我OpenWrt接入两路支持IPv6的宽带，但只能使用一路IPv6，无法对IPv6流量分流，所以加入IPv6地址库，技术上没问题，应用上纯属多余，没任何用途。

与IPv4不同，当前的路由器系统无法对来自多个运营商的IPv6体系进行统一的控制管理，并将两个以上的IPv6地址下发给同一个内网设备。

我这边可以同时下发电信和移动的IPv6地址前缀给到内网设备（Windows），不过设备决定选择用哪个IPv6地址去访问互联网还不清楚能否由路由器进行参与控制。由于OpenWrt配置mwan太折腾，我暂时切回iKuai了 😂

电信的IPv6只能走电信通道，移动的IPv6只能走移动通道，体系不同，不能交叉。

如果内网设备可以获得不同运营商的多个IPv6地址，原理上是可以加入IPv6分流功能的。

双wan都可以获取到ipv6，但是检测到的都是2409的v6地址不知道以什么规则访问的

[larsonzh]

双wan都可以获取到ipv6，但是检测到的都是2409的v6地址不知道以什么规则访问的

图中那个2409的估计是中国移动分配的地址，240e可能是中国电信地址。

不知道你路由器下的客户端设备是否能同时拥有两个IPv6地址，可到客户端上具体查看一下。IPv4情况比较简单，客户端的IPv4地址由路由器分配和管理，且只有一个地址。

若同时接入两个IPv6，并做IPv6分流，客户端设备到底该用哪个IPv6源地址访问外网的IPv6目标地址，规则如何制定，谁来管理，客户端和路由器系统谁来处理这件事情？目前不太清楚。

现实些的办法是只接入一路IPv6，如此不需做复杂的配置。

如果同时接入两路IPv6，若喜好折腾，可考虑配置为一种故障转移模式，即当前一路IPv6掉线及故障不可用时，自动切换使用另一路WAN口的IPv6，平时始终使用一路IPv6，另一路处于备用状态。此方式配置起来或许比较麻烦，如何做需有人深入研究和分享成果，本人在此仅提供上述思路。

[byff]

双wan都可以获取到ipv6，但是检测到的都是2409的v6地址不知道以什么规则访问的

图中那个2409的估计是中国移动分配的地址，240e可能是中国电信地址。

不知道你路由器下的客户端设备是否能同时拥有两个IPv6地址，可到客户端上具体查看一下。IPv4情况比较简单，客户端的IPv4地址由路由器分配和管理，且只有一个地址。

若同时接入两个IPv6，并做IPv6分流，客户端设备到底该用哪个IPv6源地址访问外网的IPv6目标地址，规则如何制定，谁来管理，客户端和路由器系统谁来处理这件事情？目前不太清楚。

现实些的办法是只接入一路IPv6，如此不需做复杂的配置。

如果同时接入两路IPv6，若喜好折腾，可考虑配置为一种故障转移模式，即当前一路IPv6掉线及故障不可用时，自动切换使用另一路WAN口的IPv6，平时始终使用一路IPv6，另一路处于备用状态。此方式配置起来或许比较麻烦，如何做需有人深入研究和分享成果，本人在此仅提供上述思路。

路由器下的设备都能获取到两个公网IPV6，可能根据设置的跃点有关，2409移动wan1_6的跃点低一些，所有的v6访问都是有这条链路，mwan3中的策略无效

[larsonzh]

路由器下的设备都能获取到两个公网IPV6，可能根据设置的跃点有关，2409移动wan1_6的跃点低一些，所有的v6访问都是有这条链路，mwan3中的策略无效

可否改变跃点值，让v6走电信？

[microka]

双wan都可以获取到ipv6，但是检测到的都是2409的v6地址不知道以什么规则访问的

图中那个2409的估计是中国移动分配的地址，240e可能是中国电信地址。
不知道你路由器下的客户端设备是否能同时拥有两个IPv6地址，可到客户端上具体查看一下。IPv4情况比较简单，客户端的IPv4地址由路由器分配和管理，且只有一个地址。
若同时接入两个IPv6，并做IPv6分流，客户端设备到底该用哪个IPv6源地址访问外网的IPv6目标地址，规则如何制定，谁来管理，客户端和路由器系统谁来处理这件事情？目前不太清楚。
现实些的办法是只接入一路IPv6，如此不需做复杂的配置。
如果同时接入两路IPv6，若喜好折腾，可考虑配置为一种故障转移模式，即当前一路IPv6掉线及故障不可用时，自动切换使用另一路WAN口的IPv6，平时始终使用一路IPv6，另一路处于备用状态。此方式配置起来或许比较麻烦，如何做需有人深入研究和分享成果，本人在此仅提供上述思路。

路由器下的设备都能获取到两个公网IPV6，可能根据设置的跃点有关，2409移动wan1_6的跃点低一些，所有的v6访问都是有这条链路，mwan3中的策略无效

我这边的情况是，下游设备能同时获取240e电信、2409移动前缀IPv6地址，访问240e目标地址会走电信v6，访问2409目标地址会走移动v6，访问其他前缀地址走哪条v6这逻辑还摸不透。不过这样也能正常用了。

[larsonzh]

我这边的情况是，下游设备能同时获取240e电信、2409移动前缀IPv6地址，访问240e目标地址会走电信v6，访问2409目标地址会走移动v6，访问其他前缀地址走哪条v6这逻辑还摸不透。不过这样也能正常用了。

在下游设备上使用路由跟踪工具测试其他IPv6目标地址流量，看看具体走哪个WAN口。

注意一定要在下游的客户端设备上测试。