I observe nearly similar behaviour.

dhcpd6.service: Main process exited, code=killed, status=6/ABRT
dhcpd6.service: Failed with result 'signal'.

I suspect there is some problem with parsing of the leases file since it begun while connecting first computer with dynamically assigned address to the network.

This is what happens in the leases file. First i notice an ABRT, then I list the file:
==============
# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\001\036\274|\017\010`ns4\270";

ia-na "\014`,\002\000\001\000\001\036G\274\015,`\014\367\037\035" {
  cltt 2 2018/10/23 12:41:25;
  iaaddr fd56:81d2:347f::f6 {
    binding state active;
    preferred-life 27000;
    max-life 43200;
    ends 3 2018/10/24 00:41:25;
  }
}

server-duid "\000\001\000\001\036\274|\017\010`ns4\270";

ia-na "\014`,\002\000\001\000\001\036G\274\015,`\014\367\037\035" {
  cltt 2 2018/10/23 12:41:25;
  iaaddr fd56:81d2:347f::f6 {
    binding state expired;
    preferred-life 27000;
    max-life 43200;
    ends 3 2018/10/24 00:41:25;
  }
}
==============

Then I restart dhcpd6.service - which immedialy ABRTs again. Looking i leases file:
==============
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.3.6

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\001\036\274|\017\010`ns4\270";

server-duid "\000\001\000\001\036\274|\017\010`ns4\270";
==============
I then restart again - normal sevice.

I'm seeing this as well.  The server crashes the first time that it gets a request, after initially giving out a prefix delegation

coredumptl reports the crash occurs here:

Stack trace of thread 3995:
                #0  0x00007fd5514bdeab raise (libc.so.6)
                #1  0x00007fd5514a85b9 abort (libc.so.6)
                #2  0x00007fd5528dcc65 isc_assertion_failed (libisc-export.so.169)
                #3  0x00007fd5528e3f0a isc_heap_delete (libisc-export.so.169)
                #4  0x000000000045a06d cleanup_old_expired (dhcpd)
                #5  0x000000000045a30f lease_timeout_support (dhcpd)
                #6  0x000000000046e80f isclib_timer_callback (dhcpd)
                #7  0x00007fd552901322 isc__taskmgr_dispatch (libisc-export.so.169)
                #8  0x00007fd552906210 evloop (libisc-export.so.169)
                #9  0x00007fd5529066d5 isc__app_ctxrun (libisc-export.so.169)
                #10 0x000000000046e71e dispatch (dhcpd)
                #11 0x00000000004084d2 main (dhcpd)
                #12 0x00007fd5514aa11b __libc_start_main (libc.so.6)
                #13 0x0000000000406bea _start (dhcpd)

In my case the server is f29, running dhcp-server-4.3.6-28.fc29.x86_64.

Would not it be better to change component to dhcp instead of dhcpv6? It seems when set to dhcpv6 it is orphaned and will never get assigned.

(In reply to Marek Greško from comment #4)
> Would not it be better to change component to dhcp instead of dhcpv6? It
> seems when set to dhcpv6 it is orphaned and will never get assigned.

Yes.  dhcpv6 has been deprecated for many years.  It should not even be a component you can select in Bugzilla, IMHO.

The bug is still orphaned. Is somebody going to look at it?

*** Bug 1686816 has been marked as a duplicate of this bug. ***

Could someone rise severity and priority on this case?

dhcp-4.3.6-23.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c82d274716

dhcp-4.3.6-30.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1918730c03

dhcp-4.3.6-33.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-59d507e0c7

dhcp-4.3.6-33.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-59d507e0c7

dhcp-4.3.6-23.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c82d274716

dhcp-4.3.6-30.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1918730c03

Hello Marek,

Would you mind testing the fix/updated package?

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

dhcp-4.3.6-33.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

bind-9.11.6-1.P1.fc29 bind-dyndb-ldap-11.1-15.fc29 dhcp-4.3.6-31.fc29 dnsperf-2.2.1-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0370ad8310

bind-9.11.6-1.P1.fc29, bind-dyndb-ldap-11.1-15.fc29, dhcp-4.3.6-31.fc29, dnsperf-2.2.1-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0370ad8310

bind-9.11.6-2.P1.fc29 bind-dyndb-ldap-11.1-15.fc29 dhcp-4.3.6-31.fc29 dnsperf-2.2.1-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0370ad8310

bind-9.11.6-2.P1.fc29, bind-dyndb-ldap-11.1-15.fc29, dhcp-4.3.6-31.fc29, dnsperf-2.2.1-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0370ad8310

*** Bug 1708642 has been marked as a duplicate of this bug. ***

bind-9.11.6-2.P1.fc29, bind-dyndb-ldap-11.1-15.fc29, dhcp-4.3.6-31.fc29, dnsperf-2.2.1-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.