Hi Dave,
> This could be an issue with how dhcp6 relay is configured between the Calix
> E7s and E9s and the
Juniper routers we use to host these subnets. We've tried various
methods in kea 2.x to get the
config to recognize the joined subnets to no avail.
I think the issue is probably with how subnet selection is working in
Kea and the source address of the relay.
I'll give a hypothetical example based on the lab subnet you have
already submitted.
Juniper router relay source address: 1234:2900:a:f::12
/64 for IA_NA: 1234:2900:b:f::/64
/48 for IA_PD: 1234:2900:c::/48
You would configure the subnet this way:
{
"id": 4338,
"user-context": {
"description": "lab-5048-e7-20-v15"
},
"relay": {
"ip-addresses": [ "1234:2900:a:f::12" ]
},
"subnet": "1234:2900:b:f::",
"pools": [
{
"pool": "1234:2900:b:f:0:0:0:0 - 1234:2900:b:f:ffff:ffff:ffff:ffff"
}
],
"pd-pools": [
{
"prefix": "1234:2900:c::",
"prefix-len": 48,
"delegated-len": 60,
"client-class": "OurDev1st"
}
]
}
I think the part you are probably missing is telling Kea that the
relay-agent source address is related to the subnet in question. Note
that you can list as many relay addresses as needed.
See here (subnets):
https://kea.readthedocs.io/en/kea-3.0.0/arm/dhcp6-srv.html#using-a-specific-relay-agent-for-a-subnet
And here (shared-networks):
https://kea.readthedocs.io/en/kea-3.0.0/arm/dhcp6-srv.html#local-and-relayed-traffic-in-shared-networks
Your prefix delegation and IA_NA subnets need not be part of the same
/48. Many ISPs choose to set aside a single /48 from which they can
allocate /64 subnets that they will assign on various network links.
The rest of the /48s are used in prefix delegation.
Thank you,
Darren Ankney
On Tue, Aug 12, 2025 at 1:30 PM Dave Calafrancesco
<d...@gvtc.drakkar.org> wrote:
>
> We've eagerly awaited this release and unlike every other software we've run,
> have immediately
> deployed it instead of taking a slower more conservative approach.
>
> The addition of forensic logging was worthy of the upgrade by itself.
>
> But, we're still fighting with an issue with our DHCP6 configurations.
>
> We are an ISP and will be deploying hundreds of /48 subnets, each of which we
> intend to delegate
> /60 spaces across 60k customers.
>
> We've had PDs working with /60 delegations for a while on the prior versions
> with no issues.
>
> But, we also have CPE devices (Calix GigaSpire routers for the most part)
> that would benefit
> from also receiving an IA_NA IP space.
>
> We have not had any success having a single shared /64 exist outside of the
> /48 defined for the
> subnet. If the /48 was primary, then only PDs are issued, if the /64 is
> primary, then only
> IA_NAs are issued. So split subnets seems to be a non-starter.
>
> This could be an issue with how dhcp6 relay is configured between the Calix
> E7s and E9s and the
> Juniper routers we use to host these subnets. We've tried various methods in
> kea 2.x to get the
> config to recognize the joined subnets to no avail.
>
> We instead turned to using a /64 of the overall /48 space to be used for
> IA_NA addresses while
> the remainder is used for /60 PDs.
>
> The only method we previously had that worked was to set my PD pool to a /49,
> eliminating 604
> quintillion addresses in the process to allow us to have a single /64.
>
> Yes, we know that we could define our PD pool inside our /48 as a /49 and
> then add a /50 and
> another /51 and a /52 and a /53 and a /54 and a /55 and a /56 and a /57 and a
> /58 and finally
> even add a /59 to my prefix pool... but that part of needing to scale this
> for 250+ /48 subnets
> to serve 60k+ customers makes that a very ugly configuration.
>
> What we expected was to see this type of config just work properly:
>
> { "id": 4338, "user-context": { "description": "lab-5048-e7-20-v15" },
> "subnet":
> "1234:2900:10f2::/48",
> "pools": [ { "pool": "1234:2900:10f2:fff8::/64" } ],
> "pd-pools": [ { "prefix": "1234:2900:10f2::", "prefix-len": 48,
> "delegated-len": 60,
> "client-class": "OurDev1st", "excluded-prefix": "1234:2900:10f2:fff8::",
> "excluded-prefix-len":
> 64 } ]
> },
>
> I've tried every variation of excluded-prefix I can conceive of and have a
> circular issue where
> the config refuses to pass the tests:
>
> Error encountered: excluded prefix 1234:2900:10f2:fff8::/64 must have the
> same common prefix
> part of 60 as the delegated prefix 1234:2900:10f2::/60
> (/etc/kea/kea-dhcp6.conf:139:18)
>
> Change things to this and allow for a /60 as my common prefix:
>
> { "id": 4338, "user-context": { "description": "lab-5048-e7-20-v15" },
> "subnet":
> "1234:2900:10f2::/48",
> "pools": [ { "pool": "1234:2900:10f2:fff0::/64" } ],
> "pd-pools": [ { "prefix": "1234:2900:10f2::", "prefix-len": 48,
> "delegated-len": 60,
> "client-class": "OurDev1st", "excluded-prefix": "1234:2900:10f2:fff0::",
> "excluded-prefix-len":
> 60 } ]
> },
>
> And error changes to this:
>
> Error encountered: Excluded prefix (60) must be longer than the delegated
> prefix length (60)
> (/etc/kea/kea-dhcp6.conf:135:18)
>
> Summary, won't accept a smaller subnet under the /60, won't accept exactly
> the /60 needed to be
> excluded from the pool that holds the /64. Yes, could use a /49 but can't
> afford to throw away
> half of my IP space because of a bug in this part of the code.
>
> And yes, have tried to setup pool ranges and such but those aren't allowed in
> the prefix
> sections either.
>
> I find it incredibly difficult to believe that we may be the first network
> have ever needed to
> use PDs and NAs for customer devices.
>
> Not a single working config has been able to be suggested by any AI or search
> or other
> configuration that I've seen that would provide both IA_NA and PDs in this
> manner.
>
> What am I doing wrong and how do I fix it????
>
>
>
> Dave Calafrancesco, Senior Network Systems Engineer - GVTC
>
> On 7/30/25 08:15, Victoria Risk wrote:
> > Kea users:
> >
> > Internet Systems Consortium is pleased to announce the release of Kea
> > 3.1.0. This is a new development branch, provided for testing. The Kea 2.4
> > branch, which was EOL as of the release of Kea 3.0, has been removed from
> > the ISC website.
> >
> > The software and release notes can be downloaded from our website
> > athttps://www.isc.org/download/#Kea. <https://www.isc.org/download/#Kea.>
> >
> > Packages for Kea 3.1.0 are available from our Cloudsmith repository at
> > https://
> > app.cloudsmith.com/isc/kea-dev <https://app.cloudsmith.com/isc/kea-dev>.
> > Release notes for Kea 3.1.0 are at:
> > https://downloads.isc.org/isc/kea/3.1.0/Kea-3.1.0-
> > ReleaseNotes.txt
> > <https://downloads.isc.org/isc/kea/3.1.0/Kea-3.1.0-ReleaseNotes.txt>
> >
> > Please note the known issue, included in the release notes, with regard to
> > upgrading on Debian systems. With this version, you must use Meson to build
> > the software.
> >
> > Thank you for using ISC’s software!
> >
> > Vicky
> >
> >
>
> --
> 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
