On Wed, 03 Nov 2010 00:25:34 +1100 Karl Auer <kauer@biplane.com.au> wrote:
On Tue, 2010-11-02 at 23:23 +1030, Mark Smith wrote:
Prefix lifetimes don't work that way - there is no such thing as a "flash" renumbering.
The lifetimes are reset with every RA the nodes see. If I reconfigure my router to start sending out RAs every N seconds, it will take a a maximum of N seconds for a new preferred lifetime to be established on all active nodes on the link. If the new preferred lifetime is zero, any addresses in the prefix will be deprecated immediately, causing other prefixes on the link to be preferred.
The new valid lifetime will be the remaining valid lifetime (if less than two hours), the newly advertised valid lifetime (if using SEND), or two hours in all other cases.
That seems pretty close to "flash renumbering"...
I consider "flash renumbering" to mean that addressing can be changed without disrupting established and ongoing communications sessions e.g. doesn't break TCP connection or UDP streams. I know that renumbering without disrupting transport protocols is fundamentally impossible to achieve regardless of what the IPv6 preferred and valid lifetimes are because transport protocols are using locators as identifiers. However, the goal should be to make transient network faults, such as a broadband service link flap, have as minimal impact as possible. Changing addresses every time that type of fault occurs makes the consequences higher for transient faults than they need to be. I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. Some people argue that applications should be built to deal with this type of situation. I think that is again asking application developers to expend effort overcoming what are networking layer faults, as it has been with NAT. I think problems are best solved where they're caused, not necessarily where their effects are worst felt. I think it's better to hide transient network faults from applications than have to make each and every application include code to deal with them. The time spent writing that code could be better spent on bug fixing, improving the application functions themselves, or writing a different one. Regards, Mark.
at least for SLAAC. DHCPv6 needs more planning.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob)
GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF