Somewhere in China mainland, some ISP sent unusual DHCPv6 DUID response to clients, so RouterOS device can’t get proper IPv6 prefix, but OpenWRT and other DHCPv6 client works.
Maybe miktotik should add a new option to ignore these bad DUIDs to get prefix .
Thanks.
Actually the 6660 DUID is “not that invalid”. RFC8415 defined the value of DUID-Type from 1 to 4, each with a different constraint on the following fields (like hardware type, time, link-local address, etc.), but they all depend on the DUID-Type.
So, it is totally fine to define a DUID whose type is 6660 and that’s all (although this is not a “unique id” in most cases), as RFC8415 states: “Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.” (RFC8415, Section 11, https://datatracker.ietf.org/doc/html/rfc8415#section-11:~:text=Clients%20and%20servers%20MUST%20NOT%20restrict
%20%20%20DUIDs%20to%20the%20types%20defined%20in%20this%20document%2C%20as%20additional%20DUID%20types
%20%20%20may%20be%20defined%20in%20the%20future.).
Apart from the technical viewpoint, requesting ISPs to change their implementation takes a very long time, during which users cannot even have an IPv6 connection, which is unreasonable, since other dhcpv6 clients (like odhcp6c in OpenWRT) work in the same scenario (dhcpv6.c, line 817 to line 821, https://github.com/openwrt/odhcp6c/blob/bcd283632ac13391aac3ebdd074d1fd832d76fa3/src/dhcpv6.c#L817-L821). We would want at least an option to “allow any kind of server duid” as a workaround. So, please consider this future request. Thanks!!
299 2023-12-16 13:49:37 memory dhcp, debug, packet send pppoe-out1 -> ff02::1:2%17
300 2023-12-16 13:49:37 memory dhcp, debug, packet type: solicit
301 2023-12-16 13:49:37 memory dhcp, debug, packet transaction-id: d38fde
302 2023-12-16 13:49:37 memory dhcp, debug, packet -> clientid: 00030001 c4ad3450 1746
303 2023-12-16 13:49:37 memory dhcp, debug, packet -> elapsed_time: 1
304 2023-12-16 13:49:37 memory dhcp, debug, packet -> rapid_commit: [empty]
305 2023-12-16 13:49:37 memory dhcp, debug, packet -> ia_pd:
306 2023-12-16 13:49:37 memory dhcp, debug, packet t1: 1800
307 2023-12-16 13:49:37 memory dhcp, debug, packet t2: 2880
308 2023-12-16 13:49:37 memory dhcp, debug, packet id: 0x11
309 2023-12-16 13:49:37 memory dhcp, debug, packet recv client: pppoe-out1 fe80::d6c1:c8ff:fe9a:7700 -> fe80::c6ad:34b1:fc50:1746
310 2023-12-16 13:49:37 memory dhcp, debug, packet type: reply
311 2023-12-16 13:49:37 memory dhcp, debug, packet transaction-id: d38fde
312 2023-12-16 13:49:37 memory dhcp, debug, packet -> clientid: 00030001 c4ad3450 1746
313 2023-12-16 13:49:37 memory dhcp, debug, packet -> serverid: 6660
314 2023-12-16 13:49:37 memory dhcp, debug, packet -> rapid_commit: [empty]
315 2023-12-16 13:49:37 memory dhcp, debug, packet -> dns_servers:
316 2023-12-16 13:49:37 memory dhcp, debug, packet 240e:56:4000:8000::69
317 2023-12-16 13:49:37 memory dhcp, debug, packet 240e:56:4000::218
318 2023-12-16 13:49:37 memory dhcp, debug, packet -> ia_pd:
319 2023-12-16 13:49:37 memory dhcp, debug, packet t1: 43200
320 2023-12-16 13:49:37 memory dhcp, debug, packet t2: 69120
321 2023-12-16 13:49:37 memory dhcp, debug, packet id: 0x11
322 2023-12-16 13:49:37 memory dhcp, debug, packet -> status: 0 - success
323 2023-12-16 13:49:37 memory dhcp, debug, packet msg: SUCCESS
324 2023-12-16 13:49:37 memory dhcp, debug, packet -> ia_prefix:
325 2023-12-16 13:49:37 memory dhcp, debug, packet prefix: 240e:39a:edb:9b60::/60
326 2023-12-16 13:49:37 memory dhcp, debug, packet valid time: 86400
327 2023-12-16 13:49:37 memory dhcp, debug, packet pref. time: 86400
328 2023-12-16 13:49:37 memory dhcp, debug bad server DUID
329 2023-12-16 13:49:39 memory dhcp, debug resending..
The same problem will occur on a large scale when it is gradually cut over to the new vBRAS. This problem should be ignored as soon as possible in ros. If there is a need for this market, otherwise these devices become useless
Active AC Name SC-CD-EY4F-vBRAS.C-1.NMAN.V6000
As RFC states, the DUID must be 2-octets long and be followed with at least one octet with the identifier itself. So the minimal length MUST be 2+1=3 octets:
https://datatracker.ietf.org/doc/html/rfc8415#section-11.1
DUID Contents
A DUID consists of a 2-octet type code represented in network byte
order, followed by a variable number of octets that make up the
actual identifier. The length of the DUID (not including the type
code) is at least 1 octet and at most 128 octets.
The reference to RFC that is mentioned in this topic (“Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future”) states that you MUST NOT restrict DUIDs to their “types”. The problem here is not the “type”. The problem is that the type is not followed by “a variable number of octets that make up the actual identifier. The length of the DUID (not including the type code) is at least 1 octet and at most 128 octets.”. Unfortunately, we do not see that we would be doing anything wrong here, the type is not followed by at least 1 octet long identifier and the problem is the server, not the client.
https://datatracker.ietf.org/doc/html/rfc8415#section-11 also states this:
Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers SHOULD NOT in any other way interpret DUIDs
So why does ROS even “validate” the DUID? the line “MUST treat DUIDs as OPAQUE VALUE” seems to be pretty clear.
As @strods explained: the DUID sent out by ISP of @OP is not DUID value, it’s only DUID type. So strictly speaking ROS can’t treat “DUID as opaque VALUE” because value in this case is NULL.
Yeah, probably wouldn’t hurt anybody if ROS accepted NULL as DUID value … but since ROS is doing things correctly (by expecting at least one byte DUID value), this is not really a bug in ROS. And hence title of this thread (I read it as “feature request”) is pretty spot on. Now we can wait and hope for MT to implement this feature.
I would still like to see a binary dump of the problematic packet. It’s feasible that RouterOS’s parser / validation is broken in some other way.
This is really annoying. Please add ignore option.
Please add this feature and ignore this duid, so we can continue to buy mikrotik, or just buy that fucking Huawei ZTE
When i change dhcp optinons to set the clienid, see the log end-lines..
If you allow modifying clientid through optimons, why reject such modifications?
Now，My miktotik device is unable to obtain the correct IPv6 prefix address in china.
I try to find resolution on Internet,but i dont find it,until i see this forum.I just knew the reason of this question.
We are really need ipv6 for Internet access.You know it is hard to make ISP change in china.
So, we hope miktotik can compatible with this mistake,This is very important for Chinese users.
If miktotik don’t plan to be compatible with this, We have to switch to openwrt or other support devices. We have no choice.
Thanks.
Give it up, proud ROUTEROS does not need to be compatible with these problems, all the fault lies with you, not ROUTEROS.
This issue has been reported for almost 2 years, but ROUTEROS still hasn’t taken any action.
It’s already October 2024 and this problem still exists, it’s ridiculous, it’s time to choose other alternatives