On Mon, 2011-07-04 at 22:12 +0930, Mark Smith wrote: > If every router supports the subnet anycast address, because it is a > mandated requirement, you can develop and deploy something that relies > on it. If the availability is limited, you end up duplicating the same > mechanism some other way at the cost of additional effort, or don't > bother at all because those additional costs are too high.
For situations apparently needing the subnet router anycast address, there is the all-routers-on-link multicast address. Not that it would normally be needed, because any node on the link has (or can cheaply build) a list of all routers on the link by just watching the RAs, something it has to do anyway. A node can then choose a router at random, or any router based on any criteria it likes. Alternatively an application can ping the all-routers-on-link multicast address and build a list of responders. There is no need for the subnet router anycast address. The subnet anycast addresses are reserved but not necessarily used. Any node actually sending to one must therefore first acquire information about which one to send to. The source of that information could just as well supply any address. On the other side of the equation, an application wanting to use one of the reserved addresses must somehow publish information about which one it is using. Again, that could just as well convey information about any address. There is no need for the subnet anycast addresses to be reserved. Seriously, I'm not being bloody-minded. I simply cannot see a good reason for either of these two reserved address sets. If someone can provide any, I will immediately retract everything I have said and maintain the opposite :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer ([email protected]) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
