[kea-dev] link-local-only operation

Templin, Fred L Fred.L.Templin at boeing.com
Fri May 15 16:49:11 UTC 2015


Hi Marcin,

> -----Original Message-----
> From: kea-dev-bounces at lists.isc.org [mailto:kea-dev-bounces at lists.isc.org] On Behalf Of Marcin Siodelski
> Sent: Friday, May 15, 2015 9:40 AM
> To: kea-dev at lists.isc.org
> 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:tomasz at isc.org]
> >> Sent: Friday, May 15, 2015 9:02 AM
> >> To: Templin, Fred L; kea-dev at lists.isc.org
> >> 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
fred.l.templin at boeing.com

> Marcin
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev


More information about the kea-dev mailing list