这是一个创建于 349 天前的主题，其中的信息可能已经有所发展或是发生改变。
提供一个无法获得 IPv6 前缀的可能原因，但是暂时无解。
宽带运营商最近割接，原来使用 HW 的接入，割接之后使用中兴的 v6000 （虚拟化的） 路由器：Mikrotik RB4011 ，Ros 7.11 ，光猫桥接。
割接之前一切正常，可以获得/56 前缀，割接之后无法获得前缀。
报障之后运维不懂（但是态度良好），一层一层向上反应，估计是到了中心机房，机房运维了解到之后表示“不可能”。 遂抓了账号的 log ，发现已经分配了两个/56 前缀和一个/64 地址（为啥这样后面说）。
本地依然看不到前缀，一直是 searching...状态。
配合机房运维抓包（机房抓 debug 信息，我在以太网口抓包）： 机房运维依然能看到响应了 DHCPv6 ，我这边依然看不到前缀。 看了一下包，发现 ROS 发了 solicit ，机房回复了 reply （含 IA 和前缀），ROS 又发了一次 solicit ，机房再次回复 relay （含有不同的 IA 和前缀）. ROS 再发 solicit 收到的回复就都是 no prefix available 了。
打开 ROS logging debug dhcp ，看到 ROS 收到 replay 之后报错“bad server DUID". 发现运营商 replay 包中的所有 server DUID 都是 6660 ，type unknown.
于是就破案了...ROS 因为上端设备回复的 server DUID ”不规范“ 没有处理包信息，丢弃了.......
于是乎解释了为什么机房运维看到其他用户都分了一个/56 前缀，而我分配了两个。 于是乎解释了为什么割接之后得不到前缀？ 因为之前 HW 设备是硬件设备，使用 LLT 方式生成 server DUID ，这样保证了一定是有效的 DUID 。
看到了另一个网上的帖子，发现这不是个例。（ https://www.77bx.com/358.html ）
但是 ROS 因为 server DUID 或者 server DUID type 触发 bad server DUID 未知，已经发邮件给 Mikrotik 要求澄清。
查阅 RFC 8415 ( https://datatracker.ietf.org/doc/html/rfc8415#section-11), 其中的表述是：
Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.
目前不确定是 ROS 还是中兴在实施 IPV6 协议过程没有完全遵守 RFC8415.
帖子意在与给各位获取不到 prefix 的伙伴提供一个新的思路。 部分设备对于 server DUID 不校验，所以不受这个问题的影响（如 openWRT 和电信自己的光猫） 感谢之前提到的帖子的作者，我给他发了邮件通报了我目前的排故过程和进展。
peace.
第 1 条附言 · 263 天前
2024-03-03 更新 Mikrotik终于回复了我的Support Case，创建于2023-12-07 （接近三个月的响应时间......） 原文如下：
Hello,
Unfortunately the DUID set by server is not valid,
( The length of the DUID (not including the type code) is at least 1 octet and at most 128 octets. The following types are currently defined: )
That's why client is not received address from it.
已经回复了要求增加忽略这个错误，但是我认为官方更改的概率很低，毕竟这是ZTE实现IPv6协议的问题。
另外已经咨询了携号转网，目前本地联通表示自己也使用了ZTE设备，并且拒绝透露具体信息，只是说可以找同小区认识的人尝试。电信方面表示不会更改服务器设置，无解。
第 2 条附言 · 238 天前
又等待了这么久，收到了官方技术支持的回复：
Hello, Yes, we had this discussions few times already, we will see what we can do.
不知道他们能干啥以及计划啥时候能做变更.....
第 3 条附言 · 220 天前
已经携号转网到联通
发现联通也用的中兴设备，猜测型号是 M6000 （具体区别和 V6000 不得而知，ZTE 网站上面信息很少）
经过一番设置之后（装维师傅表示不知道任何具体信息。。。并表示如果自己改了光猫任何信息都没有办法支持）
目前是公网 ipv4 和 ipv6 都能正常使用
告一段落....
发现联通也用的中兴设备，猜测型号是 M6000 （具体区别和 V6000 不得而知，ZTE 网站上面信息很少）
经过一番设置之后（装维师傅表示不知道任何具体信息。。。并表示如果自己改了光猫任何信息都没有办法支持）
目前是公网 ipv4 和 ipv6 都能正常使用
告一段落....
 |
1
geeglo 349 天前
哇靠，我家联通+ros ，也是一直无法获取 ipv6 ，卡在 searching ，有时候重启路由器首次连接会获取到，重新获取就失败，可能也是这个原因。
|
 |
2
supermaxisme OP 另外提供一个额外的信息
一般的运营商配置（不知道他们为什么这么弄） 有两个地址池，对应两个 server instance PPPOE 拨号之后，PPPOE 对端设备会直接分配一个/64 地址（等同于 IPv4 直接给 PPPOE 接口分配 IP 无论是公网还是私网还是假公网） 然后用户终端申请前缀，会再分配/56 或者/60 前缀。 两个地址池不同...... |
 |
3
keyfunc 349 天前
尝试通过 PPPoe Scan 扫描下，看看是不是原来的 AC 还存在，拨号时可以指定 AC Name ，看看有没有用。
|
|
4
supermaxisme OP @keyfunc 运维确认了，所有用户已经都割接到 vBRAS 了。
|
 |
5
Puteulanus 349 天前  1
之前刷到过人说这个 /t/972312#r_13621786
|
|
6
keyfunc 349 天前 1
|
 |
7
Kowloon 349 天前 via iPhone
@supermaxisme
现在的 IPv6 都是这么干的，在 BRAS 上一般有一个 /48 的子网负责给每个客户端先分配一个 /64 用来互联，再下发一个 /56 或其他长度的前缀给客户端做地址池。 |
|
8
Kowloon 349 天前 via iPhone
我之前的业务在 M6000-8 上的时候也时不时丢 IPv6 不知道是不是因为中兴有 bug……
|
 |
9
junlong 349 天前
前两天还发了个帖子来这里问，破案了。。。买点服务还要客户各个都是网络工程师，真是醉了。
|
 |
10
Damn 349 天前 via iPhone
Clients and servers MUST NOT restrict ，这不就是 ros 自作多情的锅么。在 client 这边限制了只能那几种。。
|
|
11
supermaxisme OP @keyfunc 我已经扫不到了，运维说可以手动放回去，但是将来还是要下线 HW 设备的。
|
|
12
supermaxisme OP @Damn 目前不确定是 DUID type 还是 DUID 本身触发了错误，Mikrotik 还没有回复 support ticket
|
|
13
supermaxisme OP @Kowloon 不理解这么设计是出于什么原因。
我的理解是分配/64 是为了给路由模式的光猫的，光猫自己做 NAT6 光猫是桥接的时候应当分配/56 ，这样路由器自己就分配下联设备的地址了。 但是运维说所有客户端都会提供这两个（/64 和/56 ），我觉得他说的不对，看到恩山上面的其他地区是分开处理的（路由模式和桥接模式） 只要有全球单播地址都可以互联互通，不需要先分配一个/64 啊。。。。 |
 |
14
ranaanna 349 天前 via iPhone
@supermaxisme 运维说的是对的。/64 给你的是一个单独的 LAN ，并不是只给了一个地址让你做 NAT6 用的。但/64 满足不了家宽划分子网的需求（相当于 ipv4 时代把内网分为 192.168.1.0/24 和 192.168.2.0/24 的之类需求），所以为了满足这个需求，通常 isp 会再给你/60 /56 甚至/48 。并不是 isp 慷慨，实在是 ipv6 地址多到不值什么。ipv6 的世界 NAT6 应该是不存在的
|
|
15
ranaanna 349 天前 via iPhone
@supermaxisme 意思就是如果 OP 没有划分子网的需求，完全可以用/64 前缀组网，并不需要 NAT6 。但是 OP 的意思是/64 前缀也得不到吗？
|
|
16
Kowloon 348 天前 via iPhone
@supermaxisme
换个方式理解，因为 IPv6 本质可以解放你在接入 IPv4 私网时的公网需求的，所以现在相当于 BRAS 需要先连到你客户端，把地址分别给客户端和客户端下面的设备，如果你缺少其中一个 /64 或者 /56 前缀，那么这个链路就是不完整的，所以也就没有 IPv6 用。 你视光猫就是一个透明的设备，无论是桥接模式还是路由模式，只在乎谁做 PPPoE Client 就可以，光猫路由模式接路由器本来就是一个不严谨的用法，就是不考虑以后的一个懒办法。光猫桥接，那就是路由器负责拨号，一个完整的链路是需要 BRAS 从自身的地址池里提供地址给路由器，路由器再分配从 BRAS 下发的前缀里面的地址给下面设备，所以我认为运维给你的解释没什么问题。 严格意义上说 IPv6 不是用来支撑 NAT 的，至于 NAT6 我认为只是一个玩法。 我的光猫就是桥接的，连接甚至没有使能 IPv6 只是 IPv4 单栈通道，照样有 IPv6 用，你说的恩山的路由桥接分开处理我没明白，可以具体说说吗？ |
 |
17
SHF 348 天前
杭州萧山电信，小米路由器 7000 最近也挂了，一直获取不到 IPv6 前缀，我猜可能也是这个问题，一个月之前可以的，不知道最近改了什么，宽带师傅也不懂，问就是配置没问题，而且用电信的光猫拨号确实是好的，但是我不想用光猫拨号。
|
 |
18
youx 348 天前
楼主 真是 专业 啊
|
 |
19
jason96 347 天前
我家的移动也发现了同样问题，上报上去说我 IPV6 前缀没了，不一样的是装维包括上级坚持说 IPV4 公网需要收费........辛苦解释了一大波
|
 |
20
nanofrog 347 天前
杭州电信 erx 也已阵亡，我还重新配置了一遍。只有 pppoe 能拿到/64 的地址，内网其它设备都拿不到
|
|
21
supermaxisme OP |
|
22
supermaxisme OP @jason96 运维一般都不是很了解 直接告诉他们联系机房
|
|
23
supermaxisme OP @jason96 运维一般都不是很了解 直接告诉他们联系机房
机房的可以抓包看到 |
|
24
supermaxisme OP @Kowloon 实际上没必要
/56 前缀过来，直接本地路由器就能算出来地址了。 这个前缀下面的所有链接都肯定是这个设备发出来的。 还是不懂/64 的存在有啥意义…. 嗯山的帖子我找不到了 大意说的就是/64 给路由模式 /56 等的前缀给桥接模式 |
|
25
ranaanna 346 天前 via Android
@supermaxisme #21 /64 是一个子网。如果 isp 只给一个/64 前缀，或者自己的局域网不想划分子网，完全可以用 relay mode 让局域网的所有设备都有 ipv6 的呀。/56 只是 isp 再多给你 256 个/64 子网而已
|
|
26
Kowloon 346 天前 via iPhone
@supermaxisme
只给你一个 /56 你怎么跟上端设备互联？ |
|
27
supermaxisme OP @Kowloon 自己算出来全球多播地址就通了啊……
这个前缀下面的所有流量肯定都是我这个账号的（满足了审计要求） 和上端设备互连，不是很懂你的意思，我的理解完全可以用本地链路地址实现与上端的互连，本地链路地址无法满足的（也就是需要路由的） 就用/56 前缀算出来的全球单播地址即可。 |
|
28
supermaxisme OP |
|
29
junlong 335 天前
我上周日重新拨号，又能获取到了。。。也是/64 的。
|
|
31
supermaxisme OP @SHF 看了一下 openwrt 对 Native IPv6 的定义：
Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6, DHCPv6-PD and any combination Handling of preferred and valid address and prefix lifetimes Duplicate address (DAD) and Link-MTU detection DHCPv6 Extensions: Reconfigure, Information-Refresh, SOL_MAX_RT=3600 DHCPv6 Extensions: RDNSS, DNS Search Domain, NTP, SIP, ds-lite, prefix exclusion (experimental) 看起来就是最大兼容性。 电信的小哥现在已经不回我微信了。 Mikrotik 官方到现在都没回我的 support case 。 暂时无解。 |
 |
32
Spxg 288 天前 via iPhone
刚买的设备还没回家装上，看到这个帖子立马用 pppoe-discovery 扫了一下，还好，ac 只有一个 HW NE40E ，估计不受影响
|
Select Language