IPv6 unique local address flushes on up/down

IPv6 unique local address flushes on up/down

[Chr]

Hi,

I have a problem with hostapd & IPv6... 

as you might know, or not... hostapd needs to initialize 
the interface (e.g it changes it to master/accesspoint mode,
which can only be done if the interface is down)... 

However if the interface is brought down & up again (e.g whenever
hostap starts or restarts)... the IPv6 logic flushes the unique-local ipv6 
address that I gave it (by hand) with ip addr add fddb:xyz...::1//64 dev ath0 
in /etc/network/interfaces ifup script (-probably debian specific-).

And that's bad, because bind9,ISC dhcp-server v4.1 and racoon(IPsec/VPN)
needs a static address for their records/lease database and configuration...

This wasn't problem with the old IPv4... because there the 
10.x.y.z or 192.168.a.b addresses aren't deleted when the interface 
was _reinitialized_ by the hostap...

Now my question, which _one_ should we fix the applications or the stack?!
I think the network stack, but I don't know if there are RFC about this 
issue... or is there already some flag/setting which I've missed so far?  

Regards,
	Christian

Re: IPv6 unique local address flushes on up/down

[Denis V. Lunev]

On Tue, 2008-03-25 at 15:57 +0100, Chr wrote:
> Hi,
> 
> I have a problem with hostapd & IPv6... 
> 
> as you might know, or not... hostapd needs to initialize 
> the interface (e.g it changes it to master/accesspoint mode,
> which can only be done if the interface is down)... 
> 
> However if the interface is brought down & up again (e.g whenever
> hostap starts or restarts)... the IPv6 logic flushes the unique-local ipv6 
> address that I gave it (by hand) with ip addr add fddb:xyz...::1//64 dev ath0 
> in /etc/network/interfaces ifup script (-probably debian specific-).
> 
> And that's bad, because bind9,ISC dhcp-server v4.1 and racoon(IPsec/VPN)
> needs a static address for their records/lease database and configuration...
> 
> This wasn't problem with the old IPv4... because there the 
> 10.x.y.z or 192.168.a.b addresses aren't deleted when the interface 
> was _reinitialized_ by the hostap...
> 
> Now my question, which _one_ should we fix the applications or the stack?!
> I think the network stack, but I don't know if there are RFC about this 
> issue... or is there already some flag/setting which I've missed so far?  

On interface down IPv6 stack unconditionally deletes all addresses from
the interface in the addrconf_ifdown routine.

Re: IPv6 unique local address flushes on up/down

[YOSHIFUJI Hideaki / 吉藤英明]

In article <200803251557.21563.chunkeey@web.de> (at Tue, 25 Mar 2008 15:57:21 +0100), Chr <chunkeey@web.de> says:

> Now my question, which _one_ should we fix the applications or the stack?!
> I think the network stack, but I don't know if there are RFC about this 
> issue... or is there already some flag/setting which I've missed so far?  

Well..., in fact, this is known as an uneasy-to-fix issue.
The behavior han not been changed for long time, so you definately
need to have work-around for this issue, anyway.

>From specification point of view, we need to re-perform DAD (duplicate
address detection) after down-up cycle or even link-down and up.
One possible way is to add "tentative" flag for static addresses
(instead of purging them) when the interface is going down and
reperform DAD for all of such addresses when the interface is coming up.
If the link is being down, we might want to use "Optimistic" DAD instead.

--yoshfuji

Re: IPv6 unique local address flushes on up/down

[Chr]

On Tuesday 25 March 2008 16:24:28 YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <200803251557.21563.chunkeey@web.de> (at Tue, 25 Mar 2008 
15:57:21 +0100), Chr <chunkeey@web.de> says:
> > Now my question, which _one_ should we fix the applications or the
> > stack?! I think the network stack, but I don't know if there are RFC
> > about this issue... or is there already some flag/setting which I've
> > missed so far?
>
> Well..., in fact, this is known as an uneasy-to-fix issue.
> The behavior han not been changed for long time, so you definately
> need to have work-around for this issue, anyway.
>
> From specification point of view, we need to re-perform DAD (duplicate
> address detection) after down-up cycle or even link-down and up.
> One possible way is to add "tentative" flag for static addresses
> (instead of purging them) when the interface is going down and
> reperform DAD for all of such addresses when the interface is coming up.
> If the link is being down, we might want to use "Optimistic" DAD instead.
>
Ah yeah, ok... I guess... alright! ... 

but another question, about this issue form the userspace side.

Since I'm going to use the stateful DHCPv6 way... I'm wondering how I can set 
the tentative flag from userspace?

Because the DHCPv6 Client uses the ip utility to add the ipv6 address too.
And unlike the _static_ setting for the router, this _stateful_ 
autoconf-address should be flushed on ifup/down, right? 

And according to the manual page of my iproute (debian sid - from 2008-01-08). 
the ip utility doesn't have this "set flag xy for address zw" capability at 
all... 

so how can I _possibly_ set it, or prevent from being set? 
Or do I miss some good and obvious point here again?! 

Regards,
	Christian

Re: IPv6 unique local address flushes on up/down

[YOSHIFUJI Hideaki / 吉藤英明]

In article <200803251707.52528.chunkeey@web.de> (at Tue, 25 Mar 2008 17:07:52 +0100), Chr <chunkeey@web.de> says:

> On Tuesday 25 March 2008 16:24:28 YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > In article <200803251557.21563.chunkeey@web.de> (at Tue, 25 Mar 2008 
> 15:57:21 +0100), Chr <chunkeey@web.de> says:
> > > Now my question, which _one_ should we fix the applications or the
> > > stack?! I think the network stack, but I don't know if there are RFC
> > > about this issue... or is there already some flag/setting which I've
> > > missed so far?
> >
> > Well..., in fact, this is known as an uneasy-to-fix issue.
> > The behavior han not been changed for long time, so you definately
> > need to have work-around for this issue, anyway.
> >
> > From specification point of view, we need to re-perform DAD (duplicate
> > address detection) after down-up cycle or even link-down and up.
> > One possible way is to add "tentative" flag for static addresses
> > (instead of purging them) when the interface is going down and
> > reperform DAD for all of such addresses when the interface is coming up.
> > If the link is being down, we might want to use "Optimistic" DAD instead.
> >
> Ah yeah, ok... I guess... alright! ... 
> 
> but another question, about this issue form the userspace side.
> 
> Since I'm going to use the stateful DHCPv6 way... I'm wondering how I can set 
> the tentative flag from userspace?
:

Tentative flag cannot be set from userspace.
So, if we're going this way, we might need new flag for "admin" or
"static" or something alike for manual / static addresses
(including link-local addresses, probably).

--yoshfuji

Re: IPv6 unique local address flushes on up/down

[Chr]

On Tuesday 25 March 2008 17:20:39 YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <200803251707.52528.chunkeey@web.de> (at Tue, 25 Mar 2008 
17:07:52 +0100), Chr <chunkeey@web.de> says:
> > On Tuesday 25 March 2008 16:24:28 YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > > In article <200803251557.21563.chunkeey@web.de> (at Tue, 25 Mar 2008
> >
> > 15:57:21 +0100), Chr <chunkeey@web.de> says:
> > > > Now my question, which _one_ should we fix the applications or the
> > > > stack?! I think the network stack, but I don't know if there are RFC
> > > > about this issue... or is there already some flag/setting which I've
> > > > missed so far?
> > >
> > > Well..., in fact, this is known as an uneasy-to-fix issue.
> > > The behavior han not been changed for long time, so you definately
> > > need to have work-around for this issue, anyway.
> > >
> > > From specification point of view, we need to re-perform DAD (duplicate
> > > address detection) after down-up cycle or even link-down and up.
> > > One possible way is to add "tentative" flag for static addresses
> > > (instead of purging them) when the interface is going down and
> > > reperform DAD for all of such addresses when the interface is coming
> > > up. If the link is being down, we might want to use "Optimistic" DAD
> > > instead.
> >
> > Ah yeah, ok... I guess... alright! ...
> >
> > but another question, about this issue form the userspace side.
> >
> > Since I'm going to use the stateful DHCPv6 way... I'm wondering how I can
> > set the tentative flag from userspace?
>
> Tentative flag cannot be set from userspace.
> So, if we're going this way, we might need new flag for "admin" or
> "static" or something alike for manual / static addresses
> (including link-local addresses, probably).
>
> --yoshfuji
ok, this is a blocker... so, what about a "static flag" per interface instead 
of  per addresses (maybe add something 
like /proc/sys/net/ipv6/conf/ethX/address_flush).

So that on the first initialization of the interface (modprobe time) we create 
always generate a link-local address (like now)... But then on every down/up 
cycle we check the _new_ static flag.

if it is not set then we do the _old_ behaviour... (flushing everything)
and if it is set we just leave everything in place.... (and on "up", we just 
use the old link-local again instead of making a new one)

Will this work? or are there some pitfalls with this approach?
 
Regards,
	Christian