While solving the debian bug #253590 against net-tools, I discovered, that
it is not possible to turn off the link local ipv6 addresses.
net.ipv6.conf.default.autoconf does work for the received prefixes, but does
not avoid the link local configuration. (this is btw a documentation error)
I would not mind the link local address much, if there wont be some
applications (like mozilla) trying to actually use that address to reach
internet site.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253590
So my question is, how can one prevent linux kernel with build in ipv6 from
adding the link local prefix, and are the prerequisites of an ipv6 enabled
application to not prefer link local prefix to ipv4?
Greetings
Bernd
PS:
autoconf - BOOLEAN
Configure link-local addresses using L2 hardware addresses.
Default: TRUE
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Hi Bernd,
CCd: debian bug, read down to the explanation of why this is occuring
and why this is not a bug.
> While solving the debian bug #253590 against net-tools, I discovered, that
> it is not possible to turn off the link local ipv6 addresses.
Indeed.
>
> net.ipv6.conf.default.autoconf does work for the received prefixes, but does
> not avoid the link local configuration. (this is btw a documentation error)
autoconf defines whether it will auto-configure an address if a router
advertises the IPv6 prefix for the network to it.
>
> I would not mind the link local address much, if there wont be some
> applications (like mozilla) trying to actually use that address to reach
> internet site.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253590
The issue is not having the link local address, because there is no
default route and hence the connection should fail.
The problem, in the case of thi sbug, is that he has IPv6 configured,
but it is not working, 2001: is a real IPv6 address (so he has a tunnel
configured with a router to advertise) and the 2002:: is a '6ot4'
address, which something on the system has configured, and obviously
that is not working either, probably because he has a router preventing
the 6to4 packets from passsing, or the default route for the 2001:
address has a higher metric and thats still broken.
Link-local address start with fe80:: and never have a default route so
they will not be a problem.
> So my question is, how can one prevent linux kernel with build in ipv6 from
> adding the link local prefix, and are the prerequisites of an ipv6 enabled
> application to not prefer link local prefix to ipv4?
You can't, but it is not the issue here, you could however not load the
module.
Cheers,
Trent
Sixlabs
--
Trent Lloyd <[email protected]>
Bur.st Networking Inc.
On Tue, Jun 15, 2004 at 10:30:23AM +0800, Trent Lloyd wrote:
> >
> > net.ipv6.conf.default.autoconf does work for the received prefixes, but does
> > not avoid the link local configuration. (this is btw a documentation error)
>
> autoconf defines whether it will auto-configure an address if a router
> advertises the IPv6 prefix for the network to it.
Yes, but the configure help tells me otherwise. Especially since there are
two options (autoconfigure and accpet_ra) I dont think the current behavious
is intended:
autoconf - BOOLEAN
Configure link-local addresses using L2 hardware addresses.
Default: TRUE
accept_ra - BOOLEAN
Accept Router Advertisements; autoconfigure using them.
Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.
So I think autoconf=0 should avoid adding the 3ff8 link local address (as
well as lo ::1)
> The issue is not having the link local address, because there is no
> default route and hence the connection should fail.
No, please check the bug report. The problem with netscape is that it _does_
fail and not fall back to ipv4. But I think for performance reasons, no ipv6
application should actually try to contact destinations which are not in
the scope of the configured address (dont connect to sitelocal/global of only
linklocal prefix is configured)
> The problem, in the case of thi sbug, is that he has IPv6 configured,
> but it is not working, 2001: is a real IPv6 address
That was the initial problem, but we have solved that by turning autoconf
off. The last email was only with an fe80:: prefix.
> Link-local address start with fe80:: and never have a default route so
> they will not be a problem.
They are the problem, as you see above because the applications still
prefers them over ipv4.
> You can't, but it is not the issue here, you could however not load the
> module.
Yes, if it is a module. But see my comment above, I dont think the sysctl
behaves as documented, and does not behave as expected.
I can prepare a patch for this, if everybody agrees. In addition to that, I
would like to know how application and resolver can be fixed to not use
incomplete or broken v6 setups (i.e. ignore link local prefix on non local
targets without trying to connect).
Greetings
Bernd
--
(OO) -- Bernd_Eckenfels@M?rscher_Strasse_8.76185Karlsruhe.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/
o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+497211606754
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
On Tue, 2004-06-15 at 21:46 +0200, Bernd Eckenfels wrote:
> So I think autoconf=0 should avoid adding the 3ff8 link local address (as
> well as lo ::1)
3ff8 a link local address? I think you're wrong. Link local addresses
have the fe80:: prefix. 3ff8::/64 is a global unicast IPv6 address.
In article <[email protected]> you wrote:
> 3ff8 a link local address? I think you're wrong. Link local addresses
> have the fe80:: prefix. 3ff8::/64 is a global unicast IPv6 address.
Yes indeed, this was an cut+paste error, the other places in the text
correctly refer to fe80::/64.
I moved the discussion to linux-net@vger.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Hi All,
> > autoconf defines whether it will auto-configure an address if a router
> > advertises the IPv6 prefix for the network to it.
>
> Yes, but the configure help tells me otherwise. Especially since there are
> two options (autoconfigure and accpet_ra) I dont think the current behavious
> is intended:
Ahh, i see, however you would have to set autoconf to off then *remove*
the link-local addresses, because they are setup before that variable is
changed? [or is there an option for this in the kernel? afaik its just
in proc (sysctl)]
That said, the link-local addresses are *NOT* the issue here, and having
them will not cause said problems, the problem here is the user has 4
real world IPv6 addresses configured by a router on his network + user
configuration (the 6to4 address).
>
> autoconf - BOOLEAN
> Configure link-local addresses using L2 hardware addresses.
>
> Default: TRUE
>
> accept_ra - BOOLEAN
> Accept Router Advertisements; autoconfigure using them.
>
> Functional default: enabled if local forwarding is disabled.
> disabled if local forwarding is enabled.
>
>
> So I think autoconf=0 should avoid adding the 3ff8 link local address (as
> well as lo ::1)
loopback will always be configured (like in ipv4)
3ff8 isnt link local, fe80 is.
>
> > The issue is not having the link local address, because there is no
> > default route and hence the connection should fail.
>
> No, please check the bug report. The problem with netscape is that it _does_
> fail and not fall back to ipv4. But I think for performance reasons, no ipv6
> application should actually try to contact destinations which are not in
> the scope of the configured address (dont connect to sitelocal/global of only
> linklocal prefix is configured)
They won't, it acts on routing, and netscape is also broken in not
falling back.
> > The problem, in the case of thi sbug, is that he has IPv6 configured,
> > but it is not working, 2001: is a real IPv6 address
>
> That was the initial problem, but we have solved that by turning autoconf
> off. The last email was only with an fe80:: prefix.
Ah right, I didn't see that.
>
> > Link-local address start with fe80:: and never have a default route so
> > they will not be a problem.
>
> They are the problem, as you see above because the applications still
> prefers them over ipv4.
It will attempt to connect, yes, but it will do this whether you have
any addresses or not because binding a socket to AF_INET6 suceeds, in
this case netscape is just horrendously broken in not falling back and a
bug should be filed with that program.
> > You can't, but it is not the issue here, you could however not load the
> > module.
>
> Yes, if it is a module. But see my comment above, I dont think the sysctl
> behaves as documented, and does not behave as expected.
> I can prepare a patch for this, if everybody agrees. In addition to that, I
> would like to know how application and resolver can be fixed to not use
> incomplete or broken v6 setups (i.e. ignore link local prefix on non local
> targets without trying to connect).
Check out http://www.sixlabs.org/talks/, in my IPv6 programming talk I
have code showing how to use getaddrinfo() and try each address until
one suceeds.
Basically, when the application resolves and gets any number of IPv6 and
IPv4 addresses, it should try each in order until one works.
Sorry I mis-understood a little missing an email where you turned off
the global addresses.
If you need any more help, feel free to contact me privately (with
coding problems, etc), however I am limited in time and net access at
the moment so my replies may be a little delayed.
Happy hacking,
Trent
Sixlabs
--
Trent Lloyd <[email protected]>
Bur.st Networking Inc.
On Wed, Jun 16, 2004 at 08:16:31AM +0800, Trent Lloyd wrote:
> Ahh, i see, however you would have to set autoconf to off then *remove*
> the link-local addresses, because they are setup before that variable is
> changed? [or is there an option for this in the kernel? afaik its just
> in proc (sysctl)]
you can set net.ipv6.conf.defaul.autoconf=0 and then up the interface. This
will prevent it from getting any announced prefixes, but it wont prevent it
from getting linklocal prefix.
So my idea is, that autoconf=0 will prevent it from getting linklocal and
advertised adddresses and accept_ra=0 will prevent it from getting announced
prefixes.
> That said, the link-local addresses are *NOT* the issue here, and having
> them will not cause said problems, the problem here is the user has 4
> real world IPv6 addresses configured by a router on his network + user
> configuration (the 6to4 address).
Well, the user does not have them now anymore and Mozilla uses the
link-local. However I agree with you, that it might not help to remove
(prevent autoconfgration) because mozilla still might suceed in AF_INET6
binding and try the connect w/o failback.
> Check out http://www.sixlabs.org/talks/, in my IPv6 programming talk I
> have code showing how to use getaddrinfo() and try each address until
> one suceeds.
There is btw an additional issue with sending AAAA requests on a host which
is not fully configured for ipv6. In fact I think we should disable to
compile ipv6 into the kernel, its so painfull to turn the AF off.
Greetings
Bernd
--
(OO) -- Bernd_Eckenfels@M?rscher_Strasse_8.76185Karlsruhe.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/
o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+497211606754
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!