Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. link-local-only operation (Templin, Fred L)
2. DUID-EN (Templin, Fred L)
3. Re: link-local-only operation (Marcin Siodelski)
4. Re: DUID-EN (Tomek Mrugalski)
5. Re: link-local-only operation (Templin, Fred L)
6. Re: link-local-only operation (Tomek Mrugalski)
7. Re: DUID-EN (Templin, Fred L)
8. Re: link-local-only operation (Templin, Fred L)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 May 2015 14:56:32 +0000
From: "Templin, Fred L" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] link-local-only operation
Message-ID:
<2134f8430051b64f815c691a62d9831832e6c...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I have a DHCPv6 PD use case where the DHCPv6 server (acting also as a delegating
router) is always on the same link as the DHCPv6 client (acting also as a
requesting
router). There is therefore no reason that I should have to assign a
non-link-local
address and prefix to the link, since link-local-only would get the job done.
But,
kea does not appear to allow for link-local-only configurations.
In a configuration like this, it should be possible to tell the kea server to
service
all clients connected to the link even though the link itself does not have a
non-link-local address and prefix assignment. Much in the same way that you
can use "ping6 -I ifname ..." to tell ping to use link-local over a specific
interface
name. Can kea be extended to address the link-local-only use case?
Thanks - Fred
[email protected]
------------------------------
Message: 2
Date: Fri, 15 May 2015 14:58:19 +0000
From: "Templin, Fred L" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] DUID-EN
Message-ID:
<2134f8430051b64f815c691a62d9831832e6c...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I would like to configure kea to use DUID-EN as its server identifier DUID type,
but have not found a way to do so. Does kea support DUID-EN? If not, can
support be added?
Thanks - Fred
[email protected]
------------------------------
Message: 3
Date: Fri, 15 May 2015 17:11:05 +0200
From: Marcin Siodelski <[email protected]>
To: "Templin, Fred L" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] link-local-only operation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Fred,
So I want to clarify the use case. You have the client (acting as
requesting router) which only requests IA_PD for prefix delegation. This
client doesn't request IA_NA because it does not need anything above the
link-local address, as the link-local address is generated by the
device. Is this correct?
Does the server need one pool of prefixes from which it delegates
prefixes to the clients (requesting routers) on the particular link?
Marcin
On 15.05.2015 16:56, Templin, Fred L wrote:
> Hi,
>
> I have a DHCPv6 PD use case where the DHCPv6 server (acting also as a
> delegating
> router) is always on the same link as the DHCPv6 client (acting also
> as a requesting
> router). There is therefore no reason that I should have to assign a
> non-link-local
> address and prefix to the link, since link-local-only would get the
> job done. But,
> kea does not appear to allow for link-local-only configurations.
>
> In a configuration like this, it should be possible to tell the kea
> server to service
> all clients connected to the link even though the link itself does not
> have a
> non-link-local address and prefix assignment. Much in the same way
> that you
> can use "ping6 -I ifname ..." to tell ping to use link-local over a
> specific interface
> name. Can kea be extended to address the link-local-only use case?
>
> Thanks - Fred
> [email protected]
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 4
Date: Fri, 15 May 2015 17:22:47 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] DUID-EN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 15.05.2015 16:58, Templin, Fred L wrote:
> I would like to configure kea to use DUID-EN as its server identifier DUID
> type,
> but have not found a way to do so. Does kea support DUID-EN? If not, can
> support be added?
Technically, it's not supported, but you can trivially add support for
it. Start kea6 and stop it. It will store its generated DUID in
${install-dir}/var/kea/kea-dhcp6-serverid. This is the server DUID in
hex form. Feel free to generate your own DUID and put it there. I'm not
sure what your deployment model is, but you can even deploy kea with
this file, so it will use whatever DUID you want from its first start.
This possibility is (somewhat briefly) discussed in Kea User's Guide,
section 8.4. Would that work for you?
Tomek
------------------------------
Message: 5
Date: Fri, 15 May 2015 15:32:58 +0000
From: "Templin, Fred L" <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] link-local-only operation
Message-ID:
<2134f8430051b64f815c691a62d9831832e6c...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcin,
> -----Original Message-----
> From: Marcin Siodelski [mailto:[email protected]]
> Sent: Friday, May 15, 2015 8:11 AM
> To: Templin, Fred L
> Cc: [email protected]
> Subject: Re: [kea-dev] link-local-only operation
>
> Hi Fred,
>
> So I want to clarify the use case. You have the client (acting as
> requesting router) which only requests IA_PD for prefix delegation.
Correct.
> This client doesn't request IA_NA because it does not need anything above the
> link-local address, as the link-local address is generated by the
> device. Is this correct?
That is right. On it's "upstream" link over which it issues DHCPv6 PD messaging,
the client needs only link-local and will never request IA_NA. The client then
uses its delegated prefix(es) to number its "downstream" link(s).
> Does the server need one pool of prefixes from which it delegates
> prefixes to the clients (requesting routers) on the particular link?
Yes, the server has a pool of prefixes from which it delegates prefixes to the
clients on that link. In my case, I do not want to burn one or more of those
prefixes by assigning one to the link that connects the clients and servers;
I want that link to remain as link-local-only.
Thanks - Fred
[email protected]
> Marcin
>
> On 15.05.2015 16:56, Templin, Fred L wrote:
> > Hi,
> >
> > I have a DHCPv6 PD use case where the DHCPv6 server (acting also as a
> > delegating
> > router) is always on the same link as the DHCPv6 client (acting also
> > as a requesting
> > router). There is therefore no reason that I should have to assign a
> > non-link-local
> > address and prefix to the link, since link-local-only would get the
> > job done. But,
> > kea does not appear to allow for link-local-only configurations.
> >
> > In a configuration like this, it should be possible to tell the kea
> > server to service
> > all clients connected to the link even though the link itself does not
> > have a
> > non-link-local address and prefix assignment. Much in the same way
> > that you
> > can use "ping6 -I ifname ..." to tell ping to use link-local over a
> > specific interface
> > name. Can kea be extended to address the link-local-only use case?
> >
> > Thanks - Fred
> > [email protected]
> > _______________________________________________
> > kea-dev mailing list
> > [email protected]
> > https://lists.isc.org/mailman/listinfo/kea-dev
> >
------------------------------
Message: 6
Date: Fri, 15 May 2015 17:36:28 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] link-local-only operation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 15.05.2015 16:56, Templin, Fred L wrote:
> I have a DHCPv6 PD use case where the DHCPv6 server (acting also as a
> delegating
> router) is always on the same link as the DHCPv6 client (acting also as a
> requesting
> router). There is therefore no reason that I should have to assign a
> non-link-local
> address and prefix to the link, since link-local-only would get the job done.
> But,
> kea does not appear to allow for link-local-only configurations.
>
> In a configuration like this, it should be possible to tell the kea server to
> service
> all clients connected to the link even though the link itself does not have a
> non-link-local address and prefix assignment. Much in the same way that you
That is already supported. See Section 8.2.13. Note the "interface"
parameter. For any subnet, you can say that it is reachable over local
interface directly.
If I understand it correctly, you want a configuration that:
- does not assign addresses (IA_NA)
- does assign prefixes (IA_PD)
- is connected directly (not via relays)
- the interface your server connects to your clients has only link-local
address
If my understanding i correct, the following config should address your
needs:
{
"Dhcp6":
{
# Kea is told to listen on eth0 interface only.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
"lease-database": {
"type": "memfile"
},
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
# The following list defines a subnet. There's only one subnet
# in this case and it is reachable directly over eth0.
"subnet6": [.
{
"pools": [ ],
"pd-pools": [
{
"prefix": "2001:db8:1::",
"prefix-len": 56,
"delegated-len": 64
}
],
# That doesn't really matter. Kea will be unhappy if there's no
# subnet parameter.
"subnet": "2001:db8::/64",
# This tells kea that this subnet is reachable locally over eth0
"interface": "eth0"
}
]
}
}
This will cause Kea to communicate over eth0 using link-local addresses
only. It will delegate /64 prefixes out of its 2001:db8:1::/56 pool.
If clients ask for addresses (send IA_NA), they will get NoAddrsAvail in
their IA_NA responses.
Does that address your need?
Tomek
------------------------------
Message: 7
Date: Fri, 15 May 2015 15:42:03 +0000
From: "Templin, Fred L" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] DUID-EN
Message-ID:
<2134f8430051b64f815c691a62d9831832e6c...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hi Tomek,
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Tomek Mrugalski
> Sent: Friday, May 15, 2015 8:23 AM
> To: [email protected]
> Subject: Re: [kea-dev] DUID-EN
>
> On 15.05.2015 16:58, Templin, Fred L wrote:
> > I would like to configure kea to use DUID-EN as its server identifier DUID
> > type,
> > but have not found a way to do so. Does kea support DUID-EN? If not, can
> > support be added?
> Technically, it's not supported, but you can trivially add support for
> it. Start kea6 and stop it. It will store its generated DUID in
> ${install-dir}/var/kea/kea-dhcp6-serverid. This is the server DUID in
> hex form. Feel free to generate your own DUID and put it there. I'm not
> sure what your deployment model is, but you can even deploy kea with
> this file, so it will use whatever DUID you want from its first start.
It sounds like something I could do, but seems a bit cumbersome. ISC dhcp
has a configuration file option for enabling DUID-EN, so there is no need to
carry along an ancillary serverid file.
> This possibility is (somewhat briefly) discussed in Kea User's Guide,
> section 8.4. Would that work for you?
OK, but it seems like just one more configuration file to keep track of
and increases the chance of misconfigurations. It would be far simpler
if there were a configuration option that could be added to the main
kea config file.
Thanks - Fred
[email protected]
> Tomek
>
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 8
Date: Fri, 15 May 2015 15:50:57 +0000
From: "Templin, Fred L" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] link-local-only operation
Message-ID:
<2134f8430051b64f815c691a62d9831832e6c...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hi Tomek,
Responses below:
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Tomek Mrugalski
> Sent: Friday, May 15, 2015 8:36 AM
> To: [email protected]
> Subject: Re: [kea-dev] link-local-only operation
>
> On 15.05.2015 16:56, Templin, Fred L wrote:
> > I have a DHCPv6 PD use case where the DHCPv6 server (acting also as a
> > delegating
> > router) is always on the same link as the DHCPv6 client (acting also as a
> > requesting
> > router). There is therefore no reason that I should have to assign a
> > non-link-local
> > address and prefix to the link, since link-local-only would get the job
> > done. But,
> > kea does not appear to allow for link-local-only configurations.
> >
> > In a configuration like this, it should be possible to tell the kea server
> > to service
> > all clients connected to the link even though the link itself does not have
> > a
> > non-link-local address and prefix assignment. Much in the same way that you
> That is already supported. See Section 8.2.13. Note the "interface"
> parameter. For any subnet, you can say that it is reachable over local
> interface directly.
>
> If I understand it correctly, you want a configuration that:
> - does not assign addresses (IA_NA)
> - does assign prefixes (IA_PD)
> - is connected directly (not via relays)
> - the interface your server connects to your clients has only link-local
> address
>
> If my understanding i correct, the following config should address your
> needs:
>
> {
> "Dhcp6":
>
> {
> # Kea is told to listen on eth0 interface only.
> "interfaces-config": {
> "interfaces": [ "eth0" ]
> },
>
> "lease-database": {
> "type": "memfile"
> },
>
> "preferred-lifetime": 3000,
> "valid-lifetime": 4000,
> "renew-timer": 1000,
> "rebind-timer": 2000,
>
> # The following list defines a subnet. There's only one subnet
> # in this case and it is reachable directly over eth0.
> "subnet6": [.
> {
> "pools": [ ],
> "pd-pools": [
> {
> "prefix": "2001:db8:1::",
> "prefix-len": 56,
> "delegated-len": 64
> }
> ],
>
> # That doesn't really matter. Kea will be unhappy if there's no
> # subnet parameter.
> "subnet": "2001:db8::/64",
>
> # This tells kea that this subnet is reachable locally over eth0
> "interface": "eth0"
> }
> ]
> }
>
> }
>
> This will cause Kea to communicate over eth0 using link-local addresses
> only.
Yes, that is what I want. This is what I am already doing.
> It will delegate /64 prefixes out of its 2001:db8:1::/56 pool.
Good. Also what I want.
> If clients ask for addresses (send IA_NA), they will get NoAddrsAvail in
> their IA_NA responses.
Should never happen, so it is fine.
> Does that address your need?
The concern I have is this part:
> # That doesn't really matter. Kea will be unhappy if there's no
> # subnet parameter.
> "subnet": "2001:db8::/64",
That is what I mean by "burning a prefix". I don't want to have to
associate any global IPv6 prefix with the eth0 interface in any way;
I want it to be purely link-local just like for "ping6 -I eth0 fe80::1',
So, I would like to have a "no subnet" model where the only
guidance to kea is the interface name itself.
Thanks - Fred
[email protected]
> Tomek
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 14, Issue 5
**************************************
