dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2020-12-01T22:44:09Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/150Kea Migration Assistant2020-12-01T22:44:09ZAlexSSPKea Migration AssistantHi. Not found https://gitlab.isc.org/isc-projects/dhcp/-/archive/migration-assistant/dhcp-migration-assistant.tar.gzHi. Not found https://gitlab.isc.org/isc-projects/dhcp/-/archive/migration-assistant/dhcp-migration-assistant.tar.gzhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/159Providing kea-msg-compiler in prebuilt packages to allow external hook develo...2021-01-07T20:00:22ZBaptisteProviding kea-msg-compiler in prebuilt packages to allow external hook developmentI'm looking at adding CI to https://github.com/zorun/kea-hook-runscript
I would like to use your packages on Cloudsmith https://cloudsmith.io/~isc/repos/ to avoid building Kea every time.
Unfortunately, you don't ship `kea-msg-compiler...I'm looking at adding CI to https://github.com/zorun/kea-hook-runscript
I would like to use your packages on Cloudsmith https://cloudsmith.io/~isc/repos/ to avoid building Kea every time.
Unfortunately, you don't ship `kea-msg-compiler` in any package, and it's needed to build hooks.
The best package to include it would probably be `isc-kea-dev`.
Thanks!https://gitlab.isc.org/isc-projects/dhcp/-/issues/26ieee.org oui.txt URL moved2021-01-18T17:49:11ZTommy Smithieee.org oui.txt URL moved---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufac...---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt
**To Reproduce**
Steps to reproduce the behavior:
1. Remove /usr/local/etc/oui.txt
2. Run dhcp-lease-list
3. See message to "To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt"
4. Attempt to download http://standards.ieee.org/regauth/oui/oui.txt
5. Get 404 error from ieee.org
**Expected behavior**
Message from dhcp-list-list should be as follows:
To get manufacturer names please download http://standards-oui.ieee.org/oui.txt to /usr/local/etc/oui.txt
**Environment:**
- ISC DHCP version: 4.3.5 to current
- OS: e.g. Ubuntu 18.04 x64
**Additional Information**
I have a patch ready to go that updates /contrib/dhcp-lease-list.pl with the correct URL.
I need to have permissions to push the branch and then make the merge request.
**Describe the solution you'd like**
I would like permission to push a branch and then submit a merge request with the fix.
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs? No.
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code? Yes.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them. Yes4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/157host declarations not synced to failover partner2021-02-25T19:14:03ZBalakumaranhost declarations not synced to failover partnerHost declarations added with omAPI to the primary failover peer is not syncing to secondary peer.Host declarations added with omAPI to the primary failover peer is not syncing to secondary peer.https://gitlab.isc.org/isc-projects/dhcp/-/issues/162Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP se...2021-02-26T09:44:54ZTomasz Kazimierz MotylInconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.**Describe the bug**
Whilst connecting a host running dhclient of version = 4.4.1 to a network with DHCP server temporarily disabled (a brief scheduled maintenance). The observed behaviour (please find the details below) hasn't been exa...**Describe the bug**
Whilst connecting a host running dhclient of version = 4.4.1 to a network with DHCP server temporarily disabled (a brief scheduled maintenance). The observed behaviour (please find the details below) hasn't been exactly anticipated and we haven't seen any corresponding entry in the 4.4.2 release notes.
**To Reproduce**
**Dhclient config:**
```
timeout 131;
retry 33;
reboot 9;
select-timeout 3;
initial-interval 2;
interface "eth1" {
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers, vendor-encapsulated-options, dhcp-renewal-time, dhcp-rebinding-time;
require subnet-mask;
}
```
**Current time:** Wed 03 Feb 2021 12:33:20 PM PST
**Leases file - case 1 with the lease expiration set in half an hour time:**
```
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option dhcp-lease-time 3600;
option routers 10.1.1.1;
option dhcp-message-type 5;
option dhcp-server-identifier ....;
option domain-name-servers ....
option domain-name "....";
renew 3 2021/02/03 13:02:23;
rebind 3 2021/02/03 13:03:23;
expire 3 2021/02/03 13:05:23;
}
```
**Observation:**
Starts with DHCP discover (why not with DHCP request whilst the lease is still valid?), and continues search for a DHCP Server. according to the timings set-up in the config.
Now let's set the expiries for renew, rebind and expire to tomorrow date so leases file would resemble as follows (**leases' database case 2**):
```
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option routers 10.1.1.1;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option domain-name-servers ...;
option dhcp-server-identifier ...;
option domain-name "...";
renew 4 2021/02/04 13:10:16;
rebind 4 2021/02/04 13:11:16;
expire 4 2021/02/04 13:13:16;
}
```
It starts with 3 DHCP Requests (expected I daresay - we wonder why it hasn't started with DHCP requests with the sooner lease expiration date & time. It stops sending out the DHCP discover after the timeout to wake up and start sending them out around the midnight when the date will become 4th of February 2021 (unexpected).
Would there be something we do not fully realise? Is the afore an expected behaviour? If so would there be a way for a continuous DHCP discovery, whilst formerly leased IP would be in use after, timeout = 131 [s] passing and no response from a DHCP server?
**Expected behavior**
1. The behaviour ought to be consistent for both cases **1** & **2** :
- As in both cases: 1 &2 the lease is still valid dhclient should start with DHCP Request
- When the lease expiration date is set for some day in the future the DHCP Discover should not stop after timeout time
**Environment:**
- ISC DHCP version: v4.4.1
- OS: Ubuntu 20.04 x64
- Which features were compiled in
**Additional Information**
Please see **steps to reproduce**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
We haven't seen any corresponding entry in the 4.4.2 release notes.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time to consider migration?
N/A as kea is a server
- Are you sure what you would like to do is not possible using some other mechanisms?
If there is another mechanism, other than wiping out leases' DB at the boot time I would be extremely interested in getting know about it.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
Not yet. I shall ask the question with the link to this particular issue. I deem having a record is mutually beneficial.
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
It is very important to describe what you would like to do and why?
**Describe the solution you'd like**
A fix in a subsequent maintenance release.
**Describe alternatives you've considered**
It is more of a sighting at this stage and perhaps originating in some deficiency in the existent documentation. We are uncertain at this stage where the problem lies. It looks like some flaw in the logic implementation.
**Additional context**
N/A
**Funding its development**
Yup, I would be happy to donate.
**Participating in development**
I would be willing to help with testing a WIP, patch or unreleased code.
**Contacting you**
e-mail: butterfly_tm666@yahoo.com; tomasz.motyl@se.com
With my best wishes
Tomasz Motylhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/134A core dump occurs when the dhclient process runs(x86)2021-03-02T07:27:16ZyuanxinA core dump occurs when the dhclient process runs(x86)---
name: Bug report
about: A core dump occurs when the dhclient process runs a normal test case(x86).
---
**Describe the bug**
When the dhclient process is running, the client->active in the state_bound function (in the dhclinet.c fil...---
name: Bug report
about: A core dump occurs when the dhclient process runs a normal test case(x86).
---
**Describe the bug**
When the dhclient process is running, the client->active in the state_bound function (in the dhclinet.c file) accesses a null pointer.
![12](/uploads/d4c705bd7e091fb3476ea13cf6510a18/12.png)
**To Reproduce**
1.modify the dhclinet.c code.
![123](/uploads/262ce731af9ff9f15af699f2fe373b7a/123.png)
2.make: Compile the modified code.
3.run the following command:
gdb –args ./dhclient –d xxx
(xxx indicates the network adapter name.)
4.Delete the
/var/lib/dhclient/dhclient.leases
file when the gdb is suspended after running.
**Expected behavior**
A coredump occurs.
**Environment:**
- DHCP version 4.4.2
**Additional Information**
Analyze the code and construct a scenario where the white-box problem is the same as the error code. The black-box problem cannot be reproduced.
**Contacting you**
Email : 1041793952@qq.comhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/2AFTR-Name appears to be wrongly encoded2021-03-02T07:27:16ZThomas MarkwalderAFTR-Name appears to be wrongly encodedReported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 10...Reported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 1035 formating. They replied that this works fine for them. We need to open an RT ticket and change it formally, along with the others that are currently 'd', as they are also wrong.
Simply change 'd' to 'D' common/tables.c as shown the patch below:
[14126_v441.patch](/uploads/0b4d8dd045542e80832af2be669aea37/14126_v441.patch)4.1-ESV-R16Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/3Migrate RT #48575: Avoid python dependency in bind9 build2021-03-02T07:27:16ZThomas MarkwalderMigrate RT #48575: Avoid python dependency in bind9 buildBIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.BIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/4we need a contributing.md for ISC DHCP2021-03-02T07:27:17ZVicky Riskvicky@isc.orgwe need a contributing.md for ISC DHCPWe had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a pat...We had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a patch (presumably now via gitlab?)
- that your contribution will be covered by the current license for the project
- that you need to submit tests and doc for your contribution
- if there is still a contrib directory, what are the rules for what goes in there (e.g. ldap stuff?)https://gitlab.isc.org/isc-projects/dhcp/-/issues/5Delete build instructions for NextStep and other obsolete systems2021-03-02T07:27:17ZVicky Riskvicky@isc.orgDelete build instructions for NextStep and other obsolete systemsI know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we ...I know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we test on and know it works on there.)4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/6DHCPv6 lease length logging2021-03-02T07:27:17ZGhost UserDHCPv6 lease length logging---
name: DHCPv6 - on commit {} - preferred lifetime / valid lifetime incorrect values available
---
**Describe the bug**
When logging preferred and valid lifetime using on commit {} client requested values are recorded instead of serve...---
name: DHCPv6 - on commit {} - preferred lifetime / valid lifetime incorrect values available
---
**Describe the bug**
When logging preferred and valid lifetime using on commit {} client requested values are recorded instead of server provided values.
**To Reproduce**
Use a MacOS DHCPv6 client.
Add this bit to the dhcp config:
```
on commit {
if exists dhcp6.ia-na {
log(debug,
concat( "PREFERREDLIFETIME: ",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,32,4)),",",
"VALIDLIFETIME: ",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,36,4))
)
);
}
}
```
which prints a log line like this:
`Sep 15 18:53:49 dhcp-server-1 dhcpd: PREFERREDLIFETIME: 0,VALIDLIFETIME: 0`
**Expected behavior**
Should print a log line with the server provided preferred and valid lifetimes (ie: the values being sent back to the client. In my test case was 375 and 600)
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Linux (custom)
- Which features were compiled in
```
./configure --prefix=/usr \
--sysconfdir=/etc \
--enable-secs-byteorder \
--localstatedir=/var/state/dhcp \
--with-srv-lease-file=/var/state/dhcp/dhcpd.leases \
--with-srv6-lease-file=/var/state/dhcp/dhcpd6.leases \
--with-srv-pid-file=/var/run/dhcpd.pid \
--with-srv6-pid-file=/var/run/dhcpd6.pid;
```
**Additional Information**
when committing a lease to an Apple Mac mini (el Capitan) which generates a conventional log line like this:
```
Sep 15 18:53:48 dhcp-server-1 dhcpd: Relay-forward message from 2001:DB8:2e50:e8::1 port 547, link address 2001:DB8:2e50:e8::1, peer address fe80::225:4bff:fea0:6fe8
Sep 15 18:53:48 dhcp-server-1 dhcpd: Advertise NA: address 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe to client with duid 00:01:00:01:20:e5:6e:2d:00:25:4b:a0:6f:e8 iaid = 0 valid for 600 seconds
Sep 15 18:53:48 dhcp-server-1 dhcpd: Sending Relay-reply to 2001:DB8:2e50:e8::1 port 547
Sep 15 18:53:49 dhcp-server-1 dhcpd: Relay-forward message from 2001:DB8:2e50:e8::1 port 547, link address 2001:DB8:2e50:e8::1, peer address fe80::225:4bff:fea0:6fe8
Sep 15 18:53:49 dhcp-server-1 dhcpd: Reply NA: address 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe to client with duid 00:01:00:01:20:e5:6e:2d:00:25:4b:a0:6f:e8 iaid = 0 valid for 600 seconds
Sep 15 18:53:49 dhcp-server-1 dhcpd: Sending Relay-reply to 2001:DB8:2e50:e8::1 port 547
```
Using tcpdump, I can see that the client request had preferred and valid lifetimes of 0 but the reply from the server had preferred lifetime of 375 and valid lifetime of 600.
```
1505501629.303271 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 197) 2001:DB8:2e50:e8::1.547 > 2001:DB8:2e50:e4::226.547: [udp sum ok] dhcp6 relay-fwd (linkaddr=2001:DB8:2e50:e8::1 peeraddr=fe80::225:4bff:fea0:6fe8 (relay-message (dhcp6 request (xid=450fb (client-ID hwaddr/time type 1 time 551906861 00254ba06fe8) (option-request DNS-server DNS-search-list) (elapsed-time 0) (server-ID hwaddr/time type 1 time 542736789 00259061f77a) (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe pltime:0 vltime:0)))) (opt_79) (interface-ID 4769302f302f312e3234...) (Remote-ID 9 0200010000f0000a0003...))
1505501629.303633 IP6 (hlim 64, next-header UDP (17) payload length: 181) 2001:DB8:2e50:e4::226.547 > 2001:DB8:2e50:e8::1.547: [udp sum ok] dhcp6 relay-reply (linkaddr=2001:DB8:2e50:e8::1 peeraddr=fe80::225:4bff:fea0:6fe8 (interface-ID 4769302f302f312e3234...) (relay-message (dhcp6 reply (xid=450fb (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe pltime:375 vltime:600)) (client-ID hwaddr/time type 1 time 551906861 00254ba06fe8) (server-ID hwaddr/time type 1 time 542736789 00259061f77a) (DNS-server 2001:DB8:2e50:a::10 2001:DB8:2e50:a::74))))
```
It seems that option dhcp6.ia-na during the on commit {} may contain data from the client request packet instead of the server reply packet.
This seems to me like it should be considered a bug since it makes it impossible to get the lease time during on commit {}.
**Describe alternatives you've considered**
Presently I'm running tshark to extract the lease length and log it that way. This is not an ideal solution.
**Contacting you**
please contact me if you need to: perl-list at network1.netOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/7Improve error message "mdb.c(319): non-null pointer"2021-03-02T07:27:17ZCathy AlmondImprove error message "mdb.c(319): non-null pointer"Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`...Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`mdb.c(319): non-null pointer`
Having both is ambiguous and not supported - but the error message is not in the least helpful or useful for diagnosing what is wrong.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/139ipv6 address contains 'add', make conf check error2021-06-22T15:15:46Zdreamandtureipv6 address contains 'add', make conf check erroripv6 address contains 'add', make conf check error
fixed-address6 240c:4051:2125:713:add:89ff:fd63:1e42;
line 2132: Invalid IPv6 address.
fixed-address6 240c:4051:2125:713:add:
^
!...ipv6 address contains 'add', make conf check error
fixed-address6 240c:4051:2125:713:add:89ff:fd63:1e42;
line 2132: Invalid IPv6 address.
fixed-address6 240c:4051:2125:713:add:
^
![image](/uploads/6f906431f0ffffe32338c0045505d2f9/image.png)https://gitlab.isc.org/isc-projects/dhcp/-/issues/200why dhcpd offer ip always start with .1372021-09-08T16:48:21Zjinyan-0805why dhcpd offer ip always start with .137I started a dhcpd service, and i find that each time i request a ip, the dhcpd offer ip started with 10.130.52.137
the configration as flowing
```
root@Hyper:~# cat /pitrix/dvr/rtr-vjp5z8rt_dhcpd.cfg
authoritative;
ddns-update-style n...I started a dhcpd service, and i find that each time i request a ip, the dhcpd offer ip started with 10.130.52.137
the configration as flowing
```
root@Hyper:~# cat /pitrix/dvr/rtr-vjp5z8rt_dhcpd.cfg
authoritative;
ddns-update-style none;
default-lease-time 60;
max-lease-time 60;
option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;
subnet 10.130.52.0 netmask 255.255.255.0 {
range 10.130.52.2 10.130.52.136;
range 10.130.52.139 10.130.52.254;
option domain-name-servers 10.16.80.132, 119.29.29.29;
option domain-search "sh1.qingcloud.com";
option routers 10.130.52.1;
option broadcast-address 10.130.52.255;
}
```
```
Aug 1 22:46:02 sh1br52n00 dhcpd[7218]: DHCPDISCOVER from 52:54:99:93:f1:d4 via sreebjlo
Aug 1 22:46:03 sh1br52n00 dhcpd[7218]: DHCPOFFER on 10.130.52.137 to 52:54:99:93:f1:d4 (i-cnn6srad) via sreebjlo
Aug 1 22:46:03 sh1br52n00 dhcpd[7218]: DHCPREQUEST for 10.130.52.137 (10.130.52.1) from 52:54:99:93:f1:d4 (i-cnn6srad) via sreebjlo
Aug 1 22:46:03 sh1br52n00 dhcpd[7218]: DHCPACK on 10.130.52.137 to 52:54:99:93:f1:d4 (i-cnn6srad) via sreebjlo
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/217dhcrelay -6 doesn't parse -u correct when the interface name starts with t2021-11-27T00:16:10ZDaniel Loughlindhcrelay -6 doesn't parse -u correct when the interface name starts with tThe upper or -u parameter is to be formatted according to the man page: -u 2001:1:1::1%interfacename
However if the interface name begins with a t, for example -u 2001:1:1::1%team0
the %t is interpreted incorrectly resulting in the err...The upper or -u parameter is to be formatted according to the man page: -u 2001:1:1::1%interfacename
However if the interface name begins with a t, for example -u 2001:1:1::1%team0
the %t is interpreted incorrectly resulting in the error message "Interface name '2001:1:1::1/runeam0.10' too long"
It's possible to work around this issue by renaming the network adapterhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/132Feature request to support IPv6-only Preferred DHCPv4 Option2022-01-03T18:54:13ZJen LinkovaFeature request to support IPv6-only Preferred DHCPv4 Option---
name: IPv6-only Preferred DHCPv4 Option
about: Adding Option 108 support (draft-ietf-dhc-v6only) to the DHCP client
---
**Some initial questions**
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) is wi...---
name: IPv6-only Preferred DHCPv4 Option
about: Adding Option 108 support (draft-ietf-dhc-v6only) to the DHCP client
---
**Some initial questions**
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) is with RFC Editors and will be published as an RFC soon. The IANA allocated the option code 108 recently. AFAIK the ISC DHCP client does not support that option yet.
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) was produced by IETF DHC Working Group.
**Is your feature request related to a problem? Please describe.**
While migrating a network to IPv6-only mode, it might be still required to keep some devices dual-stack still. Separating IPv6-only and dual-stack hosts into different network segment does not scale very well and introduces other challenges. It's rather desirable to allow IPv6-only and dual-stack devices to coexist on the same network segment, and provide IPv4 addresses via DHCPv4 only to hosts which really need IPv4 connectivity. So what we need is a way for a host which can operate in IPv6-only mode to signal its IPv6-only readiness to the DHCPv4 server.
More details could be found in [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-1)
**Describe the solution you'd like**
The client which is willing to be IPv6-only includes the Option 108 into the PRL. If the server does not support it or the network segment does not provide IPv6-only connectivity, the server does not include the option in the response and the normal DHCPv4 process happens. So the client would receive IPv4 address. However if the network segment is IPv6-only and the server is configured to respond with the Option 108, the server includes the option into DHCPOFFER or DHCPACK. When the client receives the option 108 back, it should stop DHCPv4 process for some time.
More details could be found in:
- [Option format](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-3.1)
- [Client Behaviour](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-3.2)
**Describe alternatives you've considered**
While it's possible to achieve the similar results by silently discarding DHCPv4 packets from IPv6-only capable hosts, that approach has a serious drawback: the client never stops asking, so the load on the DHCP infrastructure increases.
**Additional context**
N/A
**Funding its development**
See below
**Participating in development**
While I'm not really proficient at writing C code and I'm not familiar with the ISC codebase, I'm happy to participate. Willing to test the client code indeed.
**Contacting you**
Email or Hangouts: furry13@gmail.com4.4.3-beta1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/113update util/bind.sh to reflect BIND9 repo branch renamed to main2022-01-03T18:54:27ZThomas Markwalderupdate util/bind.sh to reflect BIND9 repo branch renamed to mainBIND9 renamed the master branch to main. This change needs to be reflected in util/bind.shBIND9 renamed the master branch to main. This change needs to be reflected in util/bind.sh4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/108dhcpd: typo in dhcpd.conf.5 manpage2022-01-03T18:54:31ZFoster Snowhilldhcpd: typo in dhcpd.conf.5 manpageThere is a small typo in the `dhcpd.conf.5` manpage, where `prefix6` is written as `prefixy6`. This parameter doesn't seem to be mentioned anywhere else, so I assume it to be a mistake.
Patch against latest `master` below.
```diff
diff...There is a small typo in the `dhcpd.conf.5` manpage, where `prefix6` is written as `prefixy6`. This parameter doesn't seem to be mentioned anywhere else, so I assume it to be a mistake.
Patch against latest `master` below.
```diff
diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5
index d3b2ae8..9cc6b74 100644
--- a/server/dhcpd.conf.5
+++ b/server/dhcpd.conf.5
@@ -322,7 +322,7 @@ Currently it is only allowed within a \fBsubnet6\fR declaration, and
may not be included directly in a shared network declaration.
In addition to the \fBrange6\fR statement it allows the \fBprefix6\fR
statement to be included. You may include \fBrange6\fR statements
-for both NA and TA and \fBprefixy6\fR statements in a single
+for both NA and TA and \fBprefix6\fR statements in a single
\fBpool6\fR statement.
.SH DYNAMIC ADDRESS ALLOCATION
Address allocation is actually only done when a client is in the INIT
```4.4.3-beta1https://gitlab.isc.org/isc-projects/dhcp/-/issues/123dhclient runs out of all available addresses in the pool in case of abnormal ...2022-01-12T13:30:35ZAleksey Novikovdhclient runs out of all available addresses in the pool in case of abnormal script termination**Preface**
Some Linux distribution, eg. CentOS Linux 7.x or 8.x, use NetworkManager to configure network interfaces. The dhclient command started by NetworkManager looks like this:
```
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-hel...**Preface**
Some Linux distribution, eg. CentOS Linux 7.x or 8.x, use NetworkManager to configure network interfaces. The dhclient command started by NetworkManager looks like this:
```
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper \
-pf /run/NetworkManager/dhclient-<iface_name>.pid \
-lf /var/lib/NetworkManager/dhclient-<connection_uuid>-<iface_name>.lease \
-cf /var/lib/NetworkManager/dhclient-<iface_name>.conf <iface_name>
```
When dhclient receive answer from server on lease renewal it use script or binary specified by `-sf` option for IP validity checking.
```
/* If the BOUND/RENEW code detects another machine using the
offered address, it exits nonzero. We need to send a
DHCPDECLINE and toss the lease. */
if (script_go(client)) {
make_decline(client, client->new);
send_decline(client);
destroy_client_lease(client->new);
```
But the `script_go` function return non-zero result in the 2 cases:
1. Launched process exit status is non-zero. In this case `script_go` function return value > 0.
2. Launched process terminated by signal, eg. SIGTEM. In this case `script_go` function return value < 0.
**Problem description**
Let's imagine the next situation. `nm-dhcp-helper` or other script or binary specified by `-sf` option starting at some time will always terminates by SIGSEGV due to filesystem damage or some dynamic library incompatibility. In this case the dhclient will send DECLINE and retry lease renewal after 10 seconds timeout. This will repeat infinitely until all available addresses in the DHCP pool will be marked as invalid and other clients will not be able to lease an IP address.
**Solution**
To eliminate the possibility of a repetition of such a situation, it is enough in the above code fragment to replace a line
```
if (script_go(client)) {
```
by
```
if (script_go(client) > 0) {
```4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/197Improve PRNG in dhclient2022-01-12T13:57:01ZTomek MrugalskiImprove PRNG in dhclientThere is an attack on Google Compute Platform using weak randomization in dhclient publicly available here: https://github.com/irsl/gcp-dhcp-takeover-code-exec.
We became aware of this on 2021-06-30.There is an attack on Google Compute Platform using weak randomization in dhclient publicly available here: https://github.com/irsl/gcp-dhcp-takeover-code-exec.
We became aware of this on 2021-06-30.4.4.3-beta1Thomas MarkwalderThomas Markwalder