Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 511
    • Issues 511
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 56
    • Merge requests 56
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #992
Closed
Open
Created Nov 05, 2019 by Cathy Almond@cathyaDeveloper

Include the client-supplied ciaddr when ACKing DHCPINFORM [ISC-support #15515]

From Support ticket #15515

Reported on 1.5.0 but applies to all current versions of Kea DHCP

Some very fussy clients are ignoring ACKs to DHCPINFORMs sent by Kea DHCP. The only significant difference we can see between 'acceptable' and 'unacceptable' is whether or not CIADDR is returned to the client in the ACK. Kea DHCP is setting ciaddr to zero, even if the client supplied it in the DHCPINFORM, and despite using it to unicast the response to the client.

RFC2131 is a little ambiguous on the matter and says in section 4.3.1 "'ciaddr' from DHCPREQUEST or 0".

Kea DHCP has clearly taken this to mean 'the server can choose whether to send ciaddr or "0"', whereas I personally would have read this to mean 'if the client sent ciaddr, then echo it back to them, otherwise send "0"'.

There was a clarification document submitted, but it has expired and did not become an RFC: https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06

In there, the author writes:

In the DHCPACK reply:

o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the exception noted below), and 'giaddr' fields MUST be copied from the client's DHCPINFORM

I'm with the clarification document on this - I think we should be sending ciaddr back to the client if it sent ciaddr to us in the DHCPINFORM.

(I suspect, looking at the author of it, that ISC DHCP does what the clarification document suggests, so this could become a migration issue too?)

Edited Dec 03, 2019 by Support RT
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking