Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 594
    • Issues 594
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 61
    • Merge requests 61
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and 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 ProjectsISC Open Source Projects
  • KeaKea
  • Issues
  • #2660
Closed
Open
Issue created Dec 01, 2022 by Silvester van der Leer@svdleer

DHCPv6 Reply packet with double IAADDR, one has correct preferred-lft one has wrong preferred-lft after RENEW

Hello,

We are the most current version of Kea-2.2.0 stable release.

And we see sometimes double IAADDR packets in the reply DHCPv6 messages coming from Kea after a RENEW It causes the clients to behave strange.

2022-12-01 11:13:53.125 DEBUG [kea-dhcp6.packets/21263.140484500109184] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[2001:db8:f000:10:16:8:151]:547 remoteAddr=[2001:db9:12::1]:547
msgtype=7(REPLY), transid=0x1ed800
type=00001, len=00010: 00:03:00:01:a8:70:5d:28:47:70
type=00002, len=00014: 00:01:00:01:26:ab:0a:f5:00:0c:29:b5:01:6c
type=00003(IA_NA), len=00068: iaid=1562920816, t1=1800, t2=2880,
options:
  type=00005(IAADDR), len=00024: address=2001:db9:12::15, preferred-lft=3600, valid-lft=7200
**  type=00005(IAADDR), len=00024: address=2001:db9:12::15, preferred-lft=0, valid-lft=0**
type=00017, len=00088: 4491 (uint32),
options:
  type=00034, len=00032: 2001:db8:f000:10:16:8:10 2001:db8:f000:10:101:0:192
  type=00037, len=00016: 2001:db8:f000:10:16:8:151
  type=00038, len=00004: 3600 (int32)
  type=00061, len=00016: 2001:b88:2::
1 relay(s):
relay[0]: msg-type=13(RELAY_REPLY), hop-count=1,
link-address=2001:db9:12::1, peer-address=fe80::aa70:5dff:fe28:4770, 1 option(s)
type=00018, len=00019: 0b:00:00:00:00:20:00:80:14:a8:70:5d:28:47:70:00:00:01:00

How can this behavior explained? It should not be possible to my opinion.

Edited Dec 02, 2022 by Silvester van der Leer
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking