Re: Bug#253590: How to turn off IPV6 (link local)

[Trent Lloyd]

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 <lathiat@xxxxxx>
Bur.st Networking Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/