dhclient -6 binds unadvertised address (#93) · Issues · ISC Open Source Projects / dhcp

dhclient -6 binds unadvertised address

name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both

Describe the bug After dhclient -6 releases a leased address, and restarts, it sends a Solicit requesting that address again. If the DHCP server decides the client needs a different address (like if the system has switched to a different network, or the address was leased to another client), and includes the different address in the Advertise, dhclient winds up calling dhclient-script BOUND6 for both the old address and the new one. Both addresses get added to the interface.

To Reproduce Steps to reproduce the behavior:

Start dhclient -6 with empty dhclient6.leases file. See that it gets an address (AddressA) and configures it to the interface.
Run dhclient -6 -r to release it.
Either switch the interface to a different network, or change the DHCPv6 server so it will be forced to hand out a different address (AddressB) the next time dhclient runs.
Start dhclient -6 again. A packet capture will show the Solicit requesting AddressA.
DHCPv6 server responds with Advertise containing AddressB.
Client and server complete the transaction with the Request/Reply for AddressB.
dhclient-script BOUND6 action will be called twice. First for AddressA, then for AddressB.

Expected behavior AddressA should not be used, since it was not advertised to the client in Step 5 above. The host might no longer be on the network segment where that address is reachable, or the address could already be in use by another host, causing an address conflict.

Environment:

ISC DHCP version: Behavior observed on both isc-dhclient-4.4.1 and isc-dhclient-4.4.2
OS: CentOS 8.1, Dell iDRAC embedded Linux
Which features were compiled in: ISC DHCP source configure results: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Package: Name: DHCP Version: 4.4.2

C Compiler: gcc

Flags: DEFS: -DHAVE_CONFIG_H CFLAGS: -g -O2 -Wall -Werror -fno-strict-aliasing -I$(top_srcdir)/includes -I/home/user/dhcp-4.4.2/bind/include

DHCP versions: DHCPv4 and DHCPv6

Features: debug: no failover: yes execute: yes binary-leases: no dhcpv6: yes delayed-ack: yes dhcpv4o6: no relay-port: no

Developer: ATF unittests : no

Additional Information dhclient6.pcap dhclient6.log

Describe the solution you'd like Dhclient should only configure the address that was advertised and requested with the DHCPv6 server.

Participating in development Are you willing to participate in the feature development? Yes Are you willing to take part in the design discussions? Yes Are you willing to test an unreleased engineering code? Yes

Contacting you jvfranklin@gmail.com or github account jvfranklin

---
name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both

---

**Describe the bug**
After dhclient -6 releases a leased address, and restarts, it sends a Solicit requesting that address again.  If the DHCP server decides the client needs a different address (like if the system has switched to a different network, or the address was leased to another client), and includes the different address in the Advertise, dhclient winds up calling dhclient-script BOUND6 for both the old address and the new one.  Both addresses get added to the interface.

**To Reproduce**
Steps to reproduce the behavior:
1. Start dhclient -6 with empty dhclient6.leases file. See that it gets an address (AddressA) and configures it to the interface.
2. Run dhclient -6 -r to release it.
3. Either switch the interface to a different network, or change the DHCPv6 server so it will be forced to hand out a different address (AddressB) the next time dhclient runs.
4. Start dhclient -6 again.  A packet capture will show the Solicit requesting AddressA.
5. DHCPv6 server responds with Advertise containing AddressB.
6. Client and server complete the transaction with the Request/Reply for AddressB.
7. dhclient-script BOUND6 action will be called twice.  First for AddressA, then for AddressB.

**Expected behavior**
AddressA should not be used, since it was not advertised to the client in Step 5 above.  The host might no longer be on the network segment where that address is reachable, or the address could already be in use by another host, causing an address conflict.

**Environment:**
 - ISC DHCP version:  Behavior observed on both isc-dhclient-4.4.1 and isc-dhclient-4.4.2
 
 - OS: CentOS 8.1, Dell iDRAC embedded Linux
 - Which features were compiled in:
     ISC DHCP source configure results:
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Package:
  Name:          DHCP
  Version:       4.4.2

C Compiler:      gcc

Flags:
  DEFS:          -DHAVE_CONFIG_H
  CFLAGS:        -g -O2  -Wall -Werror -fno-strict-aliasing -I$(top_srcdir)/includes -I/home/user/dhcp-4.4.2/bind/include

DHCP versions:   DHCPv4 and DHCPv6

Features:
  debug:         no
  failover:      yes
  execute:       yes
  binary-leases: no
  dhcpv6:        yes
  delayed-ack:   yes
  dhcpv4o6:      no
  relay-port:    no

Developer:
  ATF unittests : no

**Additional Information**
[dhclient6.pcap](/uploads/82938f52eef5b382f68333fc81bee040/dhclient6.pcap)
[dhclient6.log](/uploads/e08f84161367366eb905e18a068dce45/dhclient6.log)

**Describe the solution you'd like**
Dhclient should only configure the address that was advertised and requested with the DHCPv6 server.

**Participating in development**
Are you willing to participate in the feature development? Yes
Are you willing to take part in the design discussions? Yes
Are you willing to test an unreleased engineering code? Yes

**Contacting you**
jvfranklin@gmail.com or github account jvfranklin