Hello all,
You can't redefine already defined options in Kea. So you can't do this:
"option-def": [
{
"space": "dhcp6",
"name": "vendor-opts",
"code": 17,
"type": "empty",
},
]
But you CAN do this:
"option-def": [
{
"space": "vendor-4491",
"name": "vendor-opts",
"code": 17,
"type": "empty",
},
]
because it is not in the "dhcp6" space where option 17 is already defined.
That being said, you don't need to do that. It won't do anything.
What Marek showed is the correct way.
Thank you,
Darren Ankney
On Fri, May 10, 2024 at 9:19 AM <mxhajducze...@gmail.com> wrote:
>
> I will let developers speak to the logic they use to tie it all together
>
>
>
> All I know is that a working configuration for me has a “option-def” section
> (example below)
>
>
>
> ### DOCSIS space for vendor-4491
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
>
>
> followed by “option-data” where previously defined options are filled in with
> value
>
>
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "data": "2600:6ce4:0:42::132"
>
> },
>
>
>
> and then finally in subnets / pools I want Option 17 to be sent out, I add to
> “option-data” statement – note that this statement causes Option 17 to be
> filled in with vendor-4491 specific data set
>
>
>
>
> {
>
>
> "space": "dhcp6",
>
>
> "name":
> "vendor-opts",
>
>
> "code": 17,
>
>
> "data": "4491"
>
>
> }
>
>
>
> I do not know, honestly, why you would need the statement you highlighted in
> red below. My config works without it.
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Sent: Friday, May 10, 2024 7:13 AM
> To: mxhajducze...@gmail.com; 'Kea user's list' <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> Yes, but it(vendor-opts) is defined under the space vendor-4491 not under the
> space dhcp6, I tried to change the space value to dhcp6 but received error.
>
>
>
> {
>
> "space": "vendor-4491",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "type": "empty",
>
> },
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: mxhajducze...@gmail.com <mxhajducze...@gmail.com>
> Date: Friday, May 10, 2024 at 9:06 AM
> To: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: RE: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> I think there is some confusion. If you’re building a new Option in a new
> space, that is different than adding vendor-specific sub-options.
> Vendor-specific option is already pre-defined under dhcp6 space (that is
> option 17), no need to re-define it.
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Sent: Friday, May 10, 2024 7:01 AM
> To: mxhajducze...@gmail.com; 'Kea user's list' <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> I think I still have a confusion, according to the section 9.2.16, if we want
> to define a nested DHCPv6 options/Custom Option Spaces, then we should do as
> below. First, we define our new option name and code under the space of
> dhcp6, then we put the new space name under ‘encapsulate’ section for those
> sub-options to use.
>
>
>
> But for this vendor-4491, I know it’s a default defined option, but shouldn’t
> it follow the same definition methodology as well? This could cause some
> confusion.
>
>
>
> "Dhcp6": {
>
> "option-def": [
>
> {
>
> "name": "container",
>
> "code": 102,
>
> "space": "dhcp6",
>
> "type": "empty",
>
> "array": false,
>
> "record-types": "",
>
> "encapsulate": "isc"
>
> },
>
> ...
>
> ],
>
> ...
>
> }
>
>
>
> "Dhcp6": {
>
> "option-def": [
>
> {
>
> "name": "subopt1",
>
> "code": 1,
>
> "space": "isc",
>
> "type": "ipv6-address",
>
> "record-types": "",
>
> "array": false,
>
> "encapsulate": ""
>
> },
>
> {
>
> "name": "subopt2",
>
> "code": 2,
>
> "space": "isc",
>
> "type": "string",
>
> "record-types": "",
>
> "array": false,
>
> "encapsulate": ""
>
> }
>
> ],
>
> ...
>
> }
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Marek Hajduczenia <mxhajducze...@gmail.com>
> Date: Thursday, May 9, 2024 at 4:29 PM
> To: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: RE: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> Happy to help !
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Sent: Thursday, May 9, 2024 2:10 PM
> To: mxhajducze...@gmail.com; 'Kea user's list' <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> Hi Marek,
>
>
>
> Yes, your understanding is right! I configured "always-send": true to all the
> sub-options and now I have one RPD come online with the IPv6 address I
> assigned. And I re-read the document again, yes, ISC has defined two spaces
> in 2.4.1. Thank you for all the help!
>
>
>
>
>
> # custom definitions
>
> ### DOCSIS space
>
> "option-def": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "type": "empty",
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "device-type",
>
> "code": 2,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "config-file",
>
> "code": 33,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "type": "int32"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> ],
>
>
>
> "client-classes": [
>
> {
>
> "name": "RPD",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'RPD'",
>
> "option-data": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "data": "2001:391:20:7004:10:0:252:120",
>
> "always-send": true
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "data": "2001:391:20:7004:10:0:252:112",
>
> "always-send": true
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "data": "0",
>
> "always-send": true
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "data": "2001:391:20:7010:10:0:254:73",
>
> "always-send": true
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "always-send": true
>
> }
>
> ]
>
> }
>
> ],
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Marek Hajduczenia <mxhajducze...@gmail.com>
> Date: Thursday, May 9, 2024 at 3:39 PM
> To: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: RE: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> I do not think that is the problem, Yu
>
>
>
> Vendor-4491 seems to be already pre-configured in Kea, at least there is some
> hinting on that. For other vendors, and options, I do have to build
> encapsulate statement into the code. For example, Option 56 is defined as
> follows, where a top level option 56 is defined in dhcp6 space, and then
> sub-option 1 is specified, with Option 56 encapsulating “ntp-server” space.
>
>
>
> ### global DHCPv6 space
>
> {
>
> "space": "dhcp6",
>
> "name": "ntp-server",
>
> "code": 56,
>
> "type": "empty",
>
> "encapsulate": "ntp-server"
>
> },
>
> {
>
> "name": "ntp-server-ip",
>
> "code": 1,
>
> "space": "ntp-server",
>
> "type": "ipv6-address",
>
> "array": true,
>
> "encapsulate": ""
>
> },
>
>
>
> The fact that you have Option 17 with 4491 space present proves my code
> works. What is missing is the fact that the RPD does not request any specific
> options, I think, so you will need to set the “always-send” flag in
> sub-options you want the system to send out. The way it works is pretty much:
> send if requested, otherwise do not.
>
>
>
> Regards
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Sent: Thursday, May 9, 2024 1:05 PM
> To: Kea user's list <kea-users@lists.isc.org>
> Cc: Marek Hajduczenia <mxhajducze...@gmail.com>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> Hi ISC team,
>
>
>
> Thanks to Marek, After I added the condition below as he suggested, now I do
> see the kea server sent the DHCP Reply packet with the option 17 with
> Enterprise ID 4491. But unfortunately, there’s no sub-options under this
> option 17.
>
>
>
> “always-send”: true
>
>
>
>
>
> I studied the examples in the document from 9.2.14 to 9.2.16 and I think it’s
> not clear. So, it defines on Custom DHCPv6 Options, DHCPv6 Vendor-Specific
> Options and Nested DHCPv6 Options (Custom Option Spaces), but how about
> Nested DHCPv6 Options in Vendor-Specific Options?
>
>
>
> If it is for nested DHCPv6 in Custom Option Spaces, then it is defined as
> follows, basically adding a new option called “container” for option 102 and
> using the statement // "encapsulate": "isc" // to tell other sub-options that
> they all under this top option . But the problem is that, in my case, option
> 17 is NOT a customized option, it is an option under space dhcp6, when I
> tried to follow the example, I got the error.
>
>
>
> “unable to override definition of option '17' in standard option space
> 'dhcp6' (/etc/kea/kea-dhcp6.conf:62:7)”
>
>
>
> Have this type of configuration tested in 2.4.1 or later?
>
>
>
> Example on document:
>
>
>
> "Dhcp6": {
>
> "option-def": [
>
> {
>
> "name": "container",
>
> "code": 102,
>
> "space": "dhcp6",
>
> "type": "empty",
>
> "array": false,
>
> "record-types": "",
>
> "encapsulate": "isc"
>
> },
>
> ...
>
> ],
>
> ...
>
> }
>
>
>
> {
>
> "Dhcp6": {
>
> "option-data": [
>
> {
>
> "name": "subopt1",
>
> "code": 1,
>
> "space": "isc",
>
> "data": "2001:db8::abcd"
>
> },
>
> {
>
> "name": "subopt2",
>
> "code": 2,
>
> "space": "isc",
>
> "data": "Hello world"
>
> },
>
> {
>
> "name": "container",
>
> "code": 102,
>
> "space": "dhcp6"
>
> }
>
> ]
>
> }
>
> }
>
>
>
> My configuration:
>
>
>
> "option-def": [
>
> { <<<<<< This is the line 62 where seems to be the issue
>
> "space": "dhcp6",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "type": "empty",
>
> "encapsulate": "vendor-4491"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "device-type",
>
> "code": 2,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "config-file",
>
> "code": 33,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "type": "int32"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> ],
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Marek Hajduczenia <mxhajducze...@gmail.com>
> Date: Thursday, May 9, 2024 at 12:07 PM
> To: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Cc: Kea user's list <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> This is a generic statement telling Kea to send a vendor-4491 space in reply
> messages. There are examples of custom vendor spaces in Kea documentation -
> this is nothing specific to CableLabs
>
>
>
> Marek
>
>
>
> On Thu, May 9, 2024 at 10:02 AM Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> wrote:
>
> Hi Marek,
>
>
>
> Thank you for the information. I am wondering if the following option defined
> by yourself or it is defined by kea? I don’t see its definition in the config
> you shared before.
>
>
>
> {
>
> "space": "dhcp6",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "data": "4491"
>
> }
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Marek Hajduczenia <mxhajducze...@gmail.com>
> Date: Wednesday, May 8, 2024 at 5:56 PM
> To: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> I do not use RPD in v6 mode so I cannot test that but perhaps try to add a
> line at the end of the new statement as follows
>
>
>
> “always-send”: true
>
>
>
> That will force transmission of Option 17 unconditionally if this class is
> matched.
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Date: Wednesday, May 8, 2024 at 2:50 PM
> To: mxhajducze...@gmail.com <mxhajducze...@gmail.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> Hi Marek,
>
>
>
> I have added, but there’s no change. I adjusted the position of this part
> configuration to the top and bottom, but still no change.
>
>
>
>
>
> "client-classes": [
>
> {
>
> "name": "RPD",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'RPD'",
>
> "option-data": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "data": "2001:391:20:7004:10:0:252:120"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "data": "2001:391:20:7004:10:0:252:112"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "name": "time-offset",
>
> "code": 38,
>
> "data": "0"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "data": "2001:391:20:7010:10:0:254:73"
>
> },
>
> {
>
> "space": "dhcp6",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "data": "4491"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Date: Wednesday, May 8, 2024 at 4:18 PM
> To: mxhajducze...@gmail.com <mxhajducze...@gmail.com>, 'Kea user's list'
> <kea-users@lists.isc.org>
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> Thank you, Marek! Let me try!
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Marek Hajduczenia <mxhajducze...@gmail.com>
> Date: Wednesday, May 8, 2024 at 4:10 PM
> To: 'Kea user's list' <kea-users@lists.isc.org>
> Cc: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Subject: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> You need to add
>
>
>
>
> {
>
>
> "space":
> "dhcp6",
>
>
> "name":
> "vendor-opts",
>
>
> "code": 17,
>
>
> "data":
> "4491"
>
>
> }
>
>
>
> to your “option-data” stanza. Otherwise, the process will not insert the
> vendor-specific entry in Option 17.
>
>
>
> Marek
>
>
>
> From: Kea-users <kea-users-boun...@lists.isc.org> On Behalf Of Xiao, Yu
> (CCI-Atlanta) via Kea-users
> Sent: Wednesday, May 8, 2024 1:46 PM
> To: Kea user's list <kea-users@lists.isc.org>
> Cc: Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com>
> Subject: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> Greetings,
>
>
>
> I configured some sub-options for DHCPv6 Option 17 for RPD use. I didn’t find
> too detailed information regarding how to customize those sub-options under
> one option such as DHCPv6 option 17. Luckily, I found some examples from
> previous discussion email. Before I added those options, I could see the
> Solicit, Advertise, Request and Reply packets between the RPD and DHCP
> server. After the configuration, now I don’t see DHCP server responded to the
> Advertise packets anymore. The Advertise packet was sent. I checked the debug
> logs, I don’t see any reasons why the Advertise packets are not sent. There’s
> no errors in the debug logs.
>
>
>
> I define those options globally while use them under the class but they are
> not working. Then I changed the configuration and use them under global
> configuration, but still no changes. I suspect my customization configuration
> for sub-options have some problem. But I don’t see any issue according to
> manual 9.2.15. DHCPv6 Vendor-Specific Options. Did I miss something in the
> configuration? I also attached my debug settings, not sure if there could be
> more detailed debug logs to help our troubleshooting process.
>
>
>
> My kea version is 2.4.1.
>
>
>
>
>
> Option related Config:
>
>
>
> # custom definitions
>
> ### DOCSIS space
>
> "option-def": [{
>
> "space": "vendor-4491",
>
> "name": "device-type",
>
> "code": 2,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "config-file",
>
> "code": 33,
>
> "type": "string"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "type": "int32"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
> ],
>
>
>
> "client-classes": [
>
> {
>
> "name": "RPD",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'RPD'",
>
> "option-data": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "csv-format": true,
>
> "data": "2001:391:20:7004:10:0:252:120"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "csv-format": true,
>
> "data": "2001:391:20:7004:10:0:252:112"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "csv-format": true,
>
> "data": "0"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "csv-format": true,
>
> "data": "2001:391:20:7010:10:0:254:73"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
> Debug config:
>
>
>
> # DHCPv6 configuration ends with the next line
>
>
>
> "loggers": [
>
> {
>
> "name": "kea-dhcp6",
>
> "output_options": [
>
> {
>
> "output": "/tmp/kea-debug.log",
>
> "maxver": 8,
>
> "maxsize": 40480000,
>
> }
>
> ],
>
> "severity": "DEBUG",
>
> "debuglevel": 99
>
> }
>
>
>
> ]
>
>
>
> Debug logs:
>
> …
>
> 2024-05-08 14:50:14.577 INFO [kea-dhcp6.leases/27581.139777794037504]
> DHCP6_LEASE_ADVERT duid=[00:03:00:01:c4:b2:39:ba:56:98], tid=0x206da9: lease
> for address 2001:391:20:7716::447 and iaid=1 will be advertised
>
> 2024-05-08 14:50:14.577 DEBUG [kea-dhcp6.leases/27581.139777794037504]
> DHCP6_LEASE_DATA duid=[00:03:00:01:c4:b2:39:ba:56:98], tid=0x206da9: detailed
> lease information for iaid=1: Type: IA_NA(0)
>
> Address: 2001:391:20:7716::447
>
> Prefix length: 128
>
> IAID: 1
>
> Pref life: 300
>
> Valid life: 400
>
> Cltt: 1715193821
>
> DUID: 00:03:00:01:c4:b2:39:ba:56:98
>
> Hardware addr: c4:b2:39:ba:56:98
>
> Subnet ID: 1
>
> Pool ID: 0
>
> State: expired-reclaimed
>
>
>
> 2024-05-08 14:50:14.577 DEBUG [kea-dhcp6.packets/27581.139777794037504]
> DHCP6_PACKET_SEND duid=[00:03:00:01:c4:b2:39:ba:56:98], tid=0x206da9: trying
> to send packet ADVERTISE (type 2) from [2001:391:20:c012::240]:547 to
> [2001:391:20:7716::1]:547 on interface ens18
>
> 2024-05-08 14:50:14.577 DEBUG [kea-dhcp6.packets/27581.139777794037504]
> DHCP6_RESPONSE_DATA responding with packet type 2 data is
> localAddr=[2001:391:20:c012::240]:547 remoteAddr=[2001:391:20:7716::1]:547
>
> msgtype=2(ADVERTISE), transid=0x206da9
>
> type=00001, len=00010: 00:03:00:01:c4:b2:39:ba:56:98
>
> type=00002, len=00014: 00:01:00:01:2d:c5:0b:41:b6:0f:80:c4:26:56
>
> type=00003(IA_NA), len=00040: iaid=1, t1=100, t2=200,
>
> options:
>
> type=00005(IAADDR), len=00024: address=2001:391:20:7716::447,
> preferred-lft=300, valid-lft=400
>
> type=39(CLIENT_FQDN), flags: (N=1, O=0, S=0), domain-name='rpdc4b239ba5698.'
> (full)
>
> 1 relay(s):
>
> relay[0]: msg-type=13(RELAY_REPLY), hop-count=0,
>
> link-address=2001:391:20:7716::1, peer-address=fe80::c6b2:39ff:feba:5698, 0
> option(s)
>
> …
>
>
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
