Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux-HA>
  3. Dev
[RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6.
keisuke.mori+ha at gmail
May 30, 2012, 11:29 PM
Post #1 of 4 (1569 views)
Permalink
I would like to propose an enhancement of IPaddr2 to support IPv6 as
well as IPv4.

I've submitted this as a pull request #97 but also posting to the ML
for a wider audience.

I would appreciate your comments and suggestions for merging this into
the upstream.

----
[RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6.
https://github.com/ClusterLabs/resource-agents/pull/97


## Benefits:

* Unify the usage, behavior and the code maintenance between IPv4 and
IPv6 on Linux.

The usage of IPaddr2 and IPv6addr are similar but they have
different parameters and different behaviors.
In particular, they may choose a different interface depending
on your configuration even if you provided similar parameters
in the past.

IPv6addr is written in C and rather hard to make improvements.
As /bin/ip already supports both IPv4 and IPv6, we can share
the most of the code of IPaddr2 written in bash.

* usable for LVS on IPv6.

IPv6addr does not support lvs_support=true and unfortunately
there is no possible way to use LVS on IPv6 right now.

IPaddr2(/bin/ip) works for LVS configurations without
enabling lvs_support both for IPv4 and IPv6.

(You don't have to remove an address on the loopback interface
if the virtual address is assigned by using /bin/ip.)

See also:
http://www.gossamer-threads.com/lists/linuxha/dev/76429#76429

* retire the old 'findif' binary.

'findif' binary is replaced by a shell script version of
findif, originally developed by lge.
See findif could be rewritten in shell :
https://github.com/ClusterLabs/resource-agents/issues/53

* easier support for other pending issues

These pending issues can be fix based on this new IPaddr2.
* Allow ipv6addr to mark new address as deprecated
https://github.com/ClusterLabs/resource-agents/issues/68
* New RA that controls IPv6 address in loopback interface
https://github.com/ClusterLabs/resource-agents/pull/77


## Notes / Changes:

* findif semantics changes

There are some incompatibility in deciding which interface to
be used when your configuration is ambiguous. But in reality
it should not be a problem as long as it's configured properly.

The changes mostly came from fixing a bug in the findif binary
(returns a wrong broadcast) or merging the difference between
(old)IPaddr2 and IPv6addr.
See the ofct test cases for details.
(case No.6, No.9, No.10, No.12, No.15 in IPaddr2v4 test cases)

Other notable changes are described below.

* "broadcast" parameter for IPv4

"broadcast" parameter may be required along with "cidr_netmask"
when you want use a different subnet mask from the static IP address.
It's because doing such calculation is difficult in the shell
script version of findif.

See the ofct test cases for details.
(case No.11, No.14, No.16, No.17 in IPaddr2v4 test cases)

This limitation may be eliminated if we would remove
brd options from the /bin/ip command line.

* loopback(lo) now requires cidr_netmask or broadcast.

See the ofct test case in the IPaddr2 ocft script.
The reason is similar to the previous one.

* loose error check for "nic" for a IPv6 link-local address.

IPv6addr was able to check this, but in the shell script it is
hard to determine a link-local address (requires bitmask calculation).
I do not think it's worth to implement it in shell.

* send_ua: a new binary

We need one new binary as a replacement of send_arp for IPv6 support.
IPv6addr.c is reused to make this command.


Note that IPv6addr RA is still there and you can continue to use
it for the backward compatibility.


## Acknowledgement

Thanks to Tomo Nozawa-san for his hard work for writing and
testing this patch.

Thanks to Lars Ellenberg for the first findif.sh implementation.
----

Best Regards,

--
Keisuke MORI
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6. [ In reply to ]
alanr at unix
May 31, 2012, 12:38 AM
Post #2 of 4 (1563 views)
Permalink
It's straightforward to determine if an IP address is link-local or not
- for an already configured address.

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 94:db:c9:3f:7c:20 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.30/24 brd 10.10.10.255 *scope global* eth1
inet6 fe80::96db:c9ff:fe3f:7c20/64 *scope link *
valid_lft forever preferred_lft forever

This works uniformly for both ipv4 and ipv6 addresses (quite nice!)

However, for addresses which are not yet up (which is unfortunately what
you're concerned with), ipv6 link-local addresses take the form
fe80:: -- followed by 64-bits of MAC addresses (48 bit
MACs are padded out)

http://en.wikipedia.org/wiki/Link-local_address

MAC addresses never begin with 4 bytes of zeros, so the regular
expression to match this is pretty straightforward. This isn't a bad
approximation (but could easily be made better):

islinklocal() {
if
echo $1 | grep -i '^fe80::[^:]*:[^:]*:[^:]*:[^:]*$' >/dev/null
then
echo "$1 is link-local"
else
echo "$1 is NOT link-local"
fi
}




On 05/31/2012 12:29 AM, Keisuke MORI wrote:
> I would like to propose an enhancement of IPaddr2 to support IPv6 as
> well as IPv4.
>
> I've submitted this as a pull request #97 but also posting to the ML
> for a wider audience.
>
> I would appreciate your comments and suggestions for merging this into
> the upstream.
>
> ----
> [RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6.
> https://github.com/ClusterLabs/resource-agents/pull/97
>
>
> ## Benefits:
>
> * Unify the usage, behavior and the code maintenance between IPv4 and
> IPv6 on Linux.
>
> The usage of IPaddr2 and IPv6addr are similar but they have
> different parameters and different behaviors.
> In particular, they may choose a different interface depending
> on your configuration even if you provided similar parameters
> in the past.
>
> IPv6addr is written in C and rather hard to make improvements.
> As /bin/ip already supports both IPv4 and IPv6, we can share
> the most of the code of IPaddr2 written in bash.
>
> * usable for LVS on IPv6.
>
> IPv6addr does not support lvs_support=true and unfortunately
> there is no possible way to use LVS on IPv6 right now.
>
> IPaddr2(/bin/ip) works for LVS configurations without
> enabling lvs_support both for IPv4 and IPv6.
>
> (You don't have to remove an address on the loopback interface
> if the virtual address is assigned by using /bin/ip.)
>
> See also:
> http://www.gossamer-threads.com/lists/linuxha/dev/76429#76429
>
> * retire the old 'findif' binary.
>
> 'findif' binary is replaced by a shell script version of
> findif, originally developed by lge.
> See findif could be rewritten in shell :
> https://github.com/ClusterLabs/resource-agents/issues/53
>
> * easier support for other pending issues
>
> These pending issues can be fix based on this new IPaddr2.
> * Allow ipv6addr to mark new address as deprecated
> https://github.com/ClusterLabs/resource-agents/issues/68
> * New RA that controls IPv6 address in loopback interface
> https://github.com/ClusterLabs/resource-agents/pull/77
>
>
> ## Notes / Changes:
>
> * findif semantics changes
>
> There are some incompatibility in deciding which interface to
> be used when your configuration is ambiguous. But in reality
> it should not be a problem as long as it's configured properly.
>
> The changes mostly came from fixing a bug in the findif binary
> (returns a wrong broadcast) or merging the difference between
> (old)IPaddr2 and IPv6addr.
> See the ofct test cases for details.
> (case No.6, No.9, No.10, No.12, No.15 in IPaddr2v4 test cases)
>
> Other notable changes are described below.
>
> * "broadcast" parameter for IPv4
>
> "broadcast" parameter may be required along with "cidr_netmask"
> when you want use a different subnet mask from the static IP address.
> It's because doing such calculation is difficult in the shell
> script version of findif.
>
> See the ofct test cases for details.
> (case No.11, No.14, No.16, No.17 in IPaddr2v4 test cases)
>
> This limitation may be eliminated if we would remove
> brd options from the /bin/ip command line.
>
> * loopback(lo) now requires cidr_netmask or broadcast.
>
> See the ofct test case in the IPaddr2 ocft script.
> The reason is similar to the previous one.
>
> * loose error check for "nic" for a IPv6 link-local address.
>
> IPv6addr was able to check this, but in the shell script it is
> hard to determine a link-local address (requires bitmask calculation).
> I do not think it's worth to implement it in shell.
>
> * send_ua: a new binary
>
> We need one new binary as a replacement of send_arp for IPv6 support.
> IPv6addr.c is reused to make this command.
>
>
> Note that IPv6addr RA is still there and you can continue to use
> it for the backward compatibility.
>
>
> ## Acknowledgement
>
> Thanks to Tomo Nozawa-san for his hard work for writing and
> testing this patch.
>
> Thanks to Lars Ellenberg for the first findif.sh implementation.
> ----
>
> Best Regards,
>
Re: [RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6. [ In reply to ]
keisuke.mori+ha at gmail
Jun 3, 2012, 11:32 PM
Post #3 of 4 (1550 views)
Permalink
Hi Alan,

Thank you for your comments.

2012/5/31 Alan Robertson <alanr@unix.sh>:
> It's straightforward to determine if an IP address is link-local or not -
> for an already configured address.
>
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
>     link/ether 94:db:c9:3f:7c:20 brd ff:ff:ff:ff:ff:ff
>     inet 10.10.10.30/24 brd 10.10.10.255 scope global eth1
>     inet6 fe80::96db:c9ff:fe3f:7c20/64 scope link
>        valid_lft forever preferred_lft forever
>
> This works uniformly for both ipv4 and ipv6 addresses (quite nice!)

It's an interesting idea, but I don't think we need to care about IPv4
link-local addresses
because users can configure using the same manner as a "regular" IP address.
(and it's used very rarely)

In the case of IPv6 link-local addresses it is almost always a wrong
configuration if nic is missing
(the socket API mandate it) so we want to check it.

>
> However, for addresses which are not yet up (which is unfortunately what
> you're concerned with), ipv6 link-local addresses take the form
>                   fe80:: -- followed by 64-bits of MAC addresses (48 bit
> MACs are padded out)
>
> http://en.wikipedia.org/wiki/Link-local_address
>
> MAC addresses never begin with 4 bytes of zeros, so the regular expression
> to match this is pretty straightforward.  This isn't a bad approximation
> (but could easily be made better):

Yes, you are right. Matching to 'fe80::' should be pretty easy and good enough.
Why I could not think of such a simple idea :)


>
> islinklocal() {
>       if
>          echo $1 | grep -i '^fe80::[^:]*:[^:]*:[^:]*:[^:]*$' >/dev/null

We should also accept 'fe80::1'.
Anyway I will look into this way.

Thanks,

--
Keisuke MORI
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [RFC] IPaddr2: Proposal patch to support the dual stack of IPv4 and IPv6. [ In reply to ]
alanr at unix
Jun 4, 2012, 7:56 AM
Post #4 of 4 (1535 views)
Permalink
On 06/04/2012 12:32 AM, Keisuke MORI wrote:
> Hi Alan,
>
> Thank you for your comments.
> It's an interesting idea, but I don't think we need to care about IPv4
> link-local addresses
> because users can configure using the same manner as a "regular" IP address.
> (and it's used very rarely)
>
> In the case of IPv6 link-local addresses it is almost always a wrong
> configuration if nic is missing
> (the socket API mandate it) so we want to check it.
>
>> However, for addresses which are not yet up (which is unfortunately what
>> you're concerned with), ipv6 link-local addresses take the form
>> fe80:: -- followed by 64-bits of MAC addresses (48 bit
>> MACs are padded out)
>>
>> http://en.wikipedia.org/wiki/Link-local_address
>>
>> MAC addresses never begin with 4 bytes of zeros, so the regular expression
>> to match this is pretty straightforward. This isn't a bad approximation
>> (but could easily be made better):
> Yes, you are right. Matching to 'fe80::' should be pretty easy and good enough.
> Why I could not think of such a simple idea :)
I'm delighted to have been of service.

I'm best at simple things ;-).


--
Alan Robertson<alanr@unix.sh> - @OSSAlanR

"Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal