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. Re: link-local-only operation (Tomek Mrugalski)
2. Re: link-local-only operation (Templin, Fred L)
3. Re: link-local-only operation (Marcin Siodelski)
4. Re: link-local-only operation (Templin, Fred L)
5. Re: DUID-EN (Tomek Mrugalski)
6. Re: DUID-EN (Templin, Fred L)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 May 2015 18:01:58 +0200
From: Tomek Mrugalski <[email protected]>
To: "Templin, Fred L" <[email protected]>,
"[email protected]" <[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 17:50, Templin, Fred L wrote:
>> 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',
I see. This part is not really used if you specify that the subnet is
reachable directly. Feel free to replace it with "subnet": "fe80::/10".
I haven't tested it, but it should work.
> So, I would like to have a "no subnet" model where the only
> guidance to kea is the interface name itself.
When you think about it, the proposal above is closer representation of
the actual network than what you're proposing. It doesn't have any
global IPv6 prefix associated with it.
Tomek
p.s.
Note to other users that may stumble upon this post some time later. In
general, it is a bad idea to tell your DHCPv6 server to manage
link-local addresses. And that's NOT what we're trying to do here. The
subnet fe80::/10 is simply a representation of the network topology and
there are no address pools defined in it, so the server will not
delegate any addresses out of it. On the other hand, the server will
delegate prefixes, but that's ok. There is no requirement for the server
to match delegated prefixes to any prefix configured locally.
------------------------------
Message: 2
Date: Fri, 15 May 2015 16:12:55 +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,
> -----Original Message-----
> From: Tomek Mrugalski [mailto:[email protected]]
> Sent: Friday, May 15, 2015 9:02 AM
> To: Templin, Fred L; [email protected]
> Subject: Re: [kea-dev] link-local-only operation
>
> On 15.05.2015 17:50, Templin, Fred L wrote:
> >> 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',
> I see. This part is not really used if you specify that the subnet is
> reachable directly. Feel free to replace it with "subnet": "fe80::/10".
> I haven't tested it, but it should work.
Yes, that is exactly what I need! Unfortunately, I will not be able to test
until the 2-message exchange for DHCPv6 PD is ready for testing. But,
I will save this change in my kea config file and be ready to test once
we get to that phase.
> > So, I would like to have a "no subnet" model where the only
> > guidance to kea is the interface name itself.
> When you think about it, the proposal above is closer representation of
> the actual network than what you're proposing. It doesn't have any
> global IPv6 prefix associated with it.
Good. This should address the need.
Thanks - Fred
[email protected]
> Tomek
>
> p.s.
> Note to other users that may stumble upon this post some time later. In
> general, it is a bad idea to tell your DHCPv6 server to manage
> link-local addresses. And that's NOT what we're trying to do here. The
> subnet fe80::/10 is simply a representation of the network topology and
> there are no address pools defined in it, so the server will not
> delegate any addresses out of it. On the other hand, the server will
> delegate prefixes, but that's ok. There is no requirement for the server
> to match delegated prefixes to any prefix configured locally.
------------------------------
Message: 3
Date: Fri, 15 May 2015 18:40:17 +0200
From: Marcin Siodelski <[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 18:12, Templin, Fred L wrote:
> Hi Tomek,
>
>> -----Original Message-----
>> From: Tomek Mrugalski [mailto:[email protected]]
>> Sent: Friday, May 15, 2015 9:02 AM
>> To: Templin, Fred L; [email protected]
>> Subject: Re: [kea-dev] link-local-only operation
>>
>> On 15.05.2015 17:50, Templin, Fred L wrote:
>>>> 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',
>> I see. This part is not really used if you specify that the subnet is
>> reachable directly. Feel free to replace it with "subnet": "fe80::/10".
>> I haven't tested it, but it should work.
>
> Yes, that is exactly what I need! Unfortunately, I will not be able to test
> until the 2-message exchange for DHCPv6 PD is ready for testing. But,
> I will save this change in my kea config file and be ready to test once
> we get to that phase.
>
FYI, the 2-way exchange (a.k.a. rapid commit) is planned for the 0.9.2
release of Kea.
Marcin
------------------------------
Message: 4
Date: Fri, 15 May 2015 16:49:11 +0000
From: "Templin, Fred L" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] link-local-only operation
Message-ID:
<2134f8430051b64f815c691a62d9831832e6d...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hi Marcin,
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Marcin Siodelski
> Sent: Friday, May 15, 2015 9:40 AM
> To: [email protected]
> Subject: Re: [kea-dev] link-local-only operation
>
>
>
> On 15.05.2015 18:12, Templin, Fred L wrote:
> > Hi Tomek,
> >
> >> -----Original Message-----
> >> From: Tomek Mrugalski [mailto:[email protected]]
> >> Sent: Friday, May 15, 2015 9:02 AM
> >> To: Templin, Fred L; [email protected]
> >> Subject: Re: [kea-dev] link-local-only operation
> >>
> >> On 15.05.2015 17:50, Templin, Fred L wrote:
> >>>> 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',
> >> I see. This part is not really used if you specify that the subnet is
> >> reachable directly. Feel free to replace it with "subnet": "fe80::/10".
> >> I haven't tested it, but it should work.
> >
> > Yes, that is exactly what I need! Unfortunately, I will not be able to test
> > until the 2-message exchange for DHCPv6 PD is ready for testing. But,
> > I will save this change in my kea config file and be ready to test once
> > we get to that phase.
> >
>
> FYI, the 2-way exchange (a.k.a. rapid commit) is planned for the 0.9.2
> release of Kea.
Thanks, yes I saw this on the ticket status. I also saw the planned release
date for 0.9.2 and I should be able to scrape by with my modified version
of ISC dhcp until then but very much looking forward to coming back to
kea. Please let me know if you need any pre-release field testing support.
Fred
[email protected]
> Marcin
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 5
Date: Fri, 15 May 2015 20:56:03 +0200
From: Tomek Mrugalski <[email protected]>
To: "Templin, Fred L" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] DUID-EN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 15.05.2015 17:42, Templin, Fred L wrote:
>> 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.
I see your point. Personally, I don't consider DUID a configuration
parameter in its classical sense. This is something that is supposed to
be generated once and kept as is for the lifetime of the server. At
least that's what was envisioned by RFC3315. I understand that there may
be specific needs that warrant tweaking server's DUID, but in my opinion
they are sufficiently uncommon that it is ok to make its edits cumbersome.
On the other hand, I would afraid that if we expose a configuration
parameter, people may get confused and think that setting their DUID by
hand is required.
Anyway, if those arguments doesn't convince you, please submit a ticket.
I honestly admit that it likely won't be implemented in the next couple
months, simply because we have lots of tickets planned already and this
is not a common feature and there is a workaround that is relatively
easy to apply. Nevertheless, hopefully we'll get round to this ticket
one day.
Tomek
------------------------------
Message: 6
Date: Fri, 15 May 2015 19:27:06 +0000
From: "Templin, Fred L" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] DUID-EN
Message-ID:
<2134f8430051b64f815c691a62d9831832e6d...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Thanks Tomek - here is the ticket:
http://kea.isc.org/ticket/3874
Fred
[email protected]
> -----Original Message-----
> From: Tomek Mrugalski [mailto:[email protected]]
> Sent: Friday, May 15, 2015 11:56 AM
> To: Templin, Fred L; [email protected]
> Subject: Re: [kea-dev] DUID-EN
>
> On 15.05.2015 17:42, Templin, Fred L wrote:
> >> 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.
> I see your point. Personally, I don't consider DUID a configuration
> parameter in its classical sense. This is something that is supposed to
> be generated once and kept as is for the lifetime of the server. At
> least that's what was envisioned by RFC3315. I understand that there may
> be specific needs that warrant tweaking server's DUID, but in my opinion
> they are sufficiently uncommon that it is ok to make its edits cumbersome.
>
> On the other hand, I would afraid that if we expose a configuration
> parameter, people may get confused and think that setting their DUID by
> hand is required.
>
> Anyway, if those arguments doesn't convince you, please submit a ticket.
> I honestly admit that it likely won't be implemented in the next couple
> months, simply because we have lots of tickets planned already and this
> is not a common feature and there is a workaround that is relatively
> easy to apply. Nevertheless, hopefully we'll get round to this ticket
> one day.
>
> Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 14, Issue 6
**************************************
