site-local/global IPv6 address failed to bind on adaptor. about resource-agents

[jackwangchina]

Anyone can follow up this issue? this issue affected me a lot .

[dmuhamedagic]

Can you try to provide the nic as well (eth0 in this case), it should work for the local link scope.

[jackwangchina]

[root@ha1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:56:a2:06:ee brd ff:ff:ff:ff:ff:ff
inet 10.20.12.119/23 brd 10.20.13.255 scope global eth0
inet6 fe80::250:56ff:fea2:6ee/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0

I tested link-local address ,it can bind on adaptor successfully ,but site-local/global(2001::1) address can not bind on eth0.

[jackwangchina]

Any update ?

[jackwangchina]

Anyone can help to fix this bug?

[dmuhamedagic]

On Mon, Feb 20, 2012 at 10:30:58PM -0800, jackwangchina wrote:

Anyone can help to fix this bug?

I guess that we need to relax the rules then. In case the user
provides the interface name and for certain scopes.

Keisuke-san, what do you make of this?

[kskmori]

I guess that jackwangchine wants to assign a virtual IPv6 address on the nic which does NOT have any static IPv6 address of the same subnet to the virtual address, correct?

At least for the current version of IPv6addr, you must have assigned a static IP address of the subnet which the virtual IP address you're going to use belongs to. It has been a typical usage in IPv4, and that's how I've been using IPv6addr too. Scopes should not do the matter here; assigning a link-local address succeeds because a static link-local address is just always there.

But yes, certainly there is such an use case that "force to use the specified nic if provided" even if the nic does not have any static IP address of the subnet.

In the case of IPaddr2 (or more specifically 'findif'), it already behaves like it; "force to use the specified nic if provided", though I'm not sure if it is intended or not.
Anyway it is also preferable to have a consistent behavior between those RAs.

The problem of this behavior is that, the RAs can not detect a configuration error any more; if an user specified a wrong nic, the RA would silently use the nic.

If it's OK with you, I'm positive to write a patch to fix it.

[kskmori]

Ah, I need to look into more about the case of site-local address...

[kskmori]

In the case of site-local addresses, there is another issue.
IPv6addr RA has never support site-local addresses. Any site-local address is skipped here:
be3596b

I don't think we should add a support for site-locals to IPv6addr in the future because

1. Since site-local addresses has been deprecated over 8 years, you should not use site-locals any more (see RFC3879).
2. Linux kernel does not support sin6_scope_id for site-locals (see man ipv6(7)).

Instead, you can use Unique Local IPv6 Unicast Addresses (FC00::/7, see RFC4193).
It should work as exactly same as global addresses.

Except about site-locals, my comment above is still valid.

[dmuhamedagic]

On Tue, Feb 21, 2012 at 09:49:06PM -0800, Keisuke MORI wrote:

But yes, certainly there is such an use case that "force to use the specified nic if provided" even if the nic does not have any static IP address of the subnet.

In the case of IPaddr2 (or more specifically 'findif'), it already behaves like it; "force to use the specified nic if provided", though I'm not sure if it is intended or not.
Anyway it is also preferable to have a consistent behavior between those RAs.

Agreed.

The problem of this behavior is that, the RAs can not detect a configuration error any more; if an user specified a wrong nic, the RA would silently use the nic.

Let's allow our users to shoot themselves in foot ;-) Seriously
though, we may log an info severity message to that extent.

If it's OK with you, I'm positive to write a patch to fix it.

Great!

On Wed, Feb 22, 2012 at 01:13:24AM -0800, Keisuke MORI wrote:

In the case of site-local addresses, there is another issue.
IPv6addr RA has never support site-local addresses. Any site-local address is skipped here:
be3596b

I don't think we should add a support for site-locals to IPv6addr in the future because

1. Since site-local addresses has been deprecated over 8 years, you should not use site-locals any more (see RFC3879).
2. Linux kernel does not support sin6_scope_id for site-locals (see man ipv6(7)).

Agreed too.

Instead, you can use Unique Local IPv6 Unicast Addresses (FC00::/7, see RFC4193).
It should work as exactly same as global addresses.

Except about site-locals, my comment above is still valid.

[kskmori]

Do you want to make it for 3.9.3 release? When would be the due date?

[jackwangchina]

I will look through the docs and test it ,Thanks for you guys feedback.

[dmuhamedagic]

On Wed, Feb 22, 2012 at 04:05:20PM -0800, Keisuke MORI wrote:

Do you want to make it for 3.9.3 release? When would be the due date?

I was just about to propose to release next week. But this is not
such an urgent issue if you're out of time.

[kskmori]

I've submitted a pull request #63 for this issues. I would appreciate if you could review and test it.
Thanks,

[dmuhamedagic]

Implemented. Closing.