Community discussions

MikroTik App
 
awm1
just joined
Topic Author
Posts: 3
Joined: Wed Mar 08, 2017 1:57 pm

DHCPv6 client problem

Wed Mar 08, 2017 3:25 pm

I'm just facing a problem with ROS DHCPv6 client. We use ISC Kea to serve both statically assigned IPv6 address and subnet for client devices. Using Kea version 1.0, everything worked OK, both TP-Link and RouterBoard devices got their addresses and prefixes. But when I tried to switch Kea to version 1.1, RouterBoard devices suddenly stopped obtaining their configuration. Their log is filled with these messages:
13:12:58 dhcp,debug,packet recv server: server1 fe80::2ca0:e376:b2b0:ee5c -> ff02::1:2 
13:12:58 dhcp,debug,packet type: solicit 
13:12:58 dhcp,debug,packet transaction-id: fa2c1f 
13:12:58 dhcp,debug,packet  -> clientid:  00010001 1e1019bc 74d4358a 59ef 
13:12:58 dhcp,debug,packet  -> ia_na:  
13:12:58 dhcp,debug,packet    t1: 0 
13:12:58 dhcp,debug,packet    t2: 0 
13:12:58 dhcp,debug,packet    id: 0x1674d435 
13:12:58 dhcp,debug,packet  -> oro: 17 23 24 39  
13:12:58 dhcp,debug,packet  -> elapsed_time: 15 
13:12:58 dhcp,debug,packet  -> vendor_class:  00000137 00084d53 46542035 2e30 
13:12:58 dhcp,debug,packet  -> unknown:  000e4157 4d2d5749 4e2d5345 52564552 
13:12:58 dhcp,debug handling only prefix delegation, discarding..
Configuration files for both version of Kea are the same. But the mechanism of the DHCPv6 response changed - Kea v1.0 sends separate responses for address and prefix delegation, v1.1 sends them in one response. There is output of Kea debug log:
- Kea v1.0:
2017-03-08 13:57:32.154 DEBUG [kea-dhcp6.packets/33688] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr
=[fe80::4aee:cff:fef2:404a]:546
msgtype=7, transid=0xb4b06f
type=00001, len=00010: 00:03:00:01:48:ee:0c:f2:40:4a
type=00002, len=00014: 00:01:00:87:20:52:bb:92:0c:c4:7a:80:2e:1b
type=00003(IA_NA), len=00040: iaid=202317888, t1=1800, t2=2880,
options:
  type=00005(IAADDR), len=00024: address=xxx:yyy:zzz:9d6:4aee:cff:fef2:404a, preferred-lft=3000, valid-lft=4000
type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2

... some other debug output, skipped ...

2017-03-08 13:57:32.155 DEBUG [kea-dhcp6.packets/33688] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::4aee:cff:fef2:404a]:546
msgtype=7, transid=0xcc87f7
type=00001, len=00010: 00:03:00:01:48:ee:0c:f2:40:4a
type=00002, len=00014: 00:01:00:87:20:52:bb:92:0c:c4:7a:80:2e:1b
type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2
type=00025(IA_PD), len=00041: iaid=202317888, t1=1800, t2=2880,
options:
  type=00026(IAPREFIX), len=00025: prefix=xxx:yyy:zzz:bb0a::/64, preferred-lft=3000, valid-lft=4000

- Kea v1.1:
2017-03-08 13:29:18.822 DEBUG [kea-dhcp6.packets/3895] DHCP6_RESPONSE_DATA responding with packet type 2 data is localAddr=[ff02::1:2]:547 remoteAddr=
[fe80::4e5e:cff:fef0:23bf]:546
msgtype=2, transid=0xb8cb66
type=00001, len=00010: 00:03:00:01:4c:5e:0c:f0:23:bf
type=00002, len=00014: 00:01:00:87:20:52:b4:fb:00:25:90:46:58:29
type=00003(IA_NA), len=00040: iaid=2, t1=1800, t2=2880,
options:
  type=00005(IAADDR), len=00024: address=xxx:yyy:zzz:7e4:4e5e:cff:fef0:23bf, preferred-lft=3000, valid-lft=4000
type=00023, len=00032: xxx:yyy:zzz:1010::3 xxx:yyy:zzz:1010::2
type=00025(IA_PD), len=00041: iaid=2, t1=1800, t2=2880,
options:
  type=00026(IAPREFIX), len=00025: prefix=xxx:yyy:zzz:30a::/64, preferred-lft=3000, valid-lft=4000
The configuration of RB clients is following:
/ipv6 dhcp-server
add address-pool=LAN-pool interface=LAN-bridge name=server1
/ipv6 address
add from-pool=LAN-pool interface=ether2
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=LAN-pool request=address,prefix
/ipv6 nd
add advertise-dns=yes hop-limit=64 interface=ether2 managed-address-configuration=yes
I've tried ROS 6.34 - 6.38.3 already and each version doesn't work with Kea v1.1, so it should't be any kind of regression. However, I want to ask if the problem is in ROS or in Kea server.
 
awm1
just joined
Topic Author
Posts: 3
Joined: Wed Mar 08, 2017 1:57 pm

Re: DHCPv6 client problem

Wed Jan 17, 2018 6:43 pm

Unfortunately, this problem still persist in v6.41. I think thad IA_NA options are recognized as the IA_PD options(according to: "handling only prefix delegation, discarding.."). I tried to use Kea v1.2, but it uses the format of messages as in v1.1
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: DHCPv6 client problem

Wed Jan 17, 2018 9:19 pm

Hmm, if I could see a packet capture of the DHCPv6 request cycle it could be verified where the fault is. RFC3633 (6) states:

6. Identity Association for Prefix Delegation

An IA_PD is a construct through which a delegating router and a
requesting router can identify, group and manage a set of related
IPv6 prefixes. Each IA_PD consists of an IAID and associated
configuration information. An IA_PD for prefixes is the equivalent
of an IA (described in RFC 3315)
for addresses.

So if a single SOLICIT is emitted from the client and it contains both an IA_NA and IA_PD as options the server is then required to return those in the advertise message. RFC3315 (17.2.2) states:

The server includes options the server will return to the client in a
subsequent Reply message. The information in these options may be
used by the client in the selection of a server if the client
receives more than one Advertise message. If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option that
the server has been configured to return to the client. The server
MAY return additional options to the client if it has been configured
to do so. The server must be aware of the recommendations on packet
sizes and the use of fragmentation in section 5 of RFC 2460.

If the Solicit message from the client included one or more IA
options, the server MUST include IA options in the Advertise message
containing any addresses that would be assigned to IAs contained in
the Solicit message from the client. If the client has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses the client would like to
receive.

A quick look seems the DHCPv6 client on the MikroTik side is at fault. Let me show you my shocked face.
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1782
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: DHCPv6 client problem

Wed Jan 17, 2018 10:09 pm

Best to raise a support ticket with MT to get that fixed then?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: DHCPv6 client problem

Wed Jan 17, 2018 10:41 pm

Yup I'd be prepared to offer PCAPs of the solicit and advertise messages.
 
awm1
just joined
Topic Author
Posts: 3
Joined: Wed Mar 08, 2017 1:57 pm

Re: DHCPv6 client problem

Fri Feb 16, 2018 9:42 am

I've created support ticket three weeks ago. Unfortunately, I haven't received any response yet.
Best to raise a support ticket with MT to get that fixed then?
 
User avatar
acruhl
Member
Member
Posts: 371
Joined: Fri Jul 03, 2015 7:22 pm

Re: DHCPv6 client problem

Fri Feb 16, 2018 3:50 pm

A quick look seems the DHCPv6 client on the MikroTik side is at fault. Let me show you my shocked face.
What specifically are you looking at? I wiresharked my DHCPv6 request, but I'm finding it hard to match up what I see in the packet vs what you posted here from the RFC.

I definitely see IA, I just don't know if it's right.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: DHCPv6 client problem

Fri Feb 16, 2018 4:59 pm

If you post the PCAP I'd be happy to review it. I haven't had a chance to gather my own yet.
 
User avatar
acruhl
Member
Member
Posts: 371
Joined: Fri Jul 03, 2015 7:22 pm

Re: DHCPv6 client problem

Sat Feb 17, 2018 6:59 am

Sounds good. I hope I attached it.

I anonymized this a bit using a hex editor, I hope I didn't mangle it. A quick look says I didn't.

My PD isn't changing anymore (it used to change every few days) so I don't want it out in the open. My ipv6 firewall filter says nobody has found me yet, would like to keep it that way.
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: 4l4R1, Amazon [Bot], iustin, kivimart, lurker888, mrbroadband, NetHorror, smirgo and 83 guests