Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ipv6addr to mark new address as deprecated #68

Closed
bradjones1 opened this issue Apr 10, 2012 · 4 comments
Closed

Allow ipv6addr to mark new address as deprecated #68

bradjones1 opened this issue Apr 10, 2012 · 4 comments

Comments

@bradjones1
Copy link

It would be nice to be able to preserve a single source IPv6 address on a host after additional addresses (usually a /64) are added to the interface. It appears most people (including me, outside the HA framework) are accomplishing this by passing preferred_lft 0 to ip addr. However that doesn't appear to be an option right now with the ipv6addr ocf agent.

I'm not much of a C programmer or I'd submit a patch. Figured I'd add an issue, though, to get some thoughts on this idea. Perhaps there's a better way to accomplish this, but I haven't found it? I tried to research using gar.conf, but it appears to be focused more on destination address selection than source addressing.

@kskmori
Copy link

kskmori commented Apr 11, 2012

Hi,

I don't have much knowledge about such configuration, but isn't address labels usable for your purpose by any chance?
http://lists.debian.org/debian-isp/2011/05/msg00047.html
http://linux-hacks.blogspot.jp/2008/07/default-address-selection-part-2.html

If we need to add a such options anyway, I would prefer using ip command rather than writing a C code in IPv6addr.
I'm just trying to write a dual-stack version of IPaddr2 for another sake,
http://www.gossamer-threads.com/lists/linuxha/dev/76429
and if once the proposal is accepted by everybody it would be pretty easy to add a configurable parameter to pass extra options to ip command.

Otherwise we could add some C code for IPv6addr RA but the new parameter would be very specific only for this purpose.

Just for my curiosity, if you don't mind, could you tell me why do you need to preserve a static source address rather than using a virtual address? Because most of users around me want to always use the virtual (newly added) address as the source address (that's why IPsrcaddr exists in IPv4), otherwise the source address would changes every time a fail over occurred.

@bradjones1
Copy link
Author

First off, thanks for responding.

Re: using labels for address selection, I am not an IP stack expert but I don't think it's an option. By the way I read it: Using labels is good if the destination address you're requesting is 1::1 and you are choosing between, say, two global addresses 1::1 and 2::1 -- it will choose the one with the shortest matching prefix. Or, a global address over one configured link-local. But since my global addresses are all on the same /64, they all pass the label rules the same. I'd love to be corrected on this, but I haven't found anything on the web indicating a way to use labels to select one of many same-subnet addresses.

I think your suggestion of a more flexible ip command RA is best; that way you can pass any options accepted by ip (there are a lot...) the preferred_lft flag being one of them.

And my reasoning is mostly with respect to predictability; calls from a server to, say, an API may be subject to IP restrictions and I shouldn't have to go back and edit those to accommodate whatever address gets added "last" at any particular time... and B) why not -- IPv6 is kinda a hobby and I'm interested in figuring it out. It's easy to accomplish this with IPv4, since the tiebreaker rule is the opposite - the FIRST address configured is the source, all other things being equal.

@kskmori
Copy link

kskmori commented Oct 4, 2012

Hi,

I have been investigating related to this and I now consider that it could be solved using address labels by the command something like:

ip addrlabel add prefix fd00:172:20:25::243 label 99

Would it work for your purpose too?

for more details and the related discussion, please see here:

I would appreciate for your any comments.
Thanks,

@kskmori
Copy link

kskmori commented Nov 5, 2012

Closing as #158 has merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants