Hi Karl, On Mon, 04 Jul 2011 14:23:47 +1000 Karl Auer <ka...@biplane.com.au> wrote:
> On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote: > > Perhaps we should wait until IPv6 traffic exceeds IPv4's before > > deciding. With the trivial amount of use that IPv6 currently has, it > > makes no sense to say history shows it hasn't been useful and should be > > deprecated. > > On the other hand, if we can see now that they are unlikely to be useful > (and IMHO we *can* see that) then we are doing the world a service by > helping all those vendors NOT implement it :-) > I'd suggest many IPv6 implementations are, while possibly not well exercised, are quite mature. Anycast addresses have been in the IPv6 specs for many years, and there are a number of implementations. Cisco's IOS supports them, as does Linux, Windows and probably Mac OS X. > There is no need for subnet anycast addresses, because any address can > be an anycast address. Only the node where an anycast address is > configured needs to know that it is an anycast address. That is, there > is no need to be able to recognise such an address from its format. Has > the use of IPv4 anycast been impeded by the inability to tell an anycast > address from an ordinary address? > IPv4 anycast is a routing/forwarding plane trick (and a fault if not intended), and only works if the designated IPv4 anycast address is off link. It is not possible under IPv4 to have an on-link anycast address, because the routing/forwarding plane isn't involved. The same routing/forwarding plane trick will work with IPv6. What has been added in IPv6 is formal support of anycast addresses that are onlink within the neighbor discovery / address resolution protocol. To do the equivalent under IPv4 ARP would have to be changed. > There is also no need for subnet router anycast addresses, because a > node wanting to contact a router can use the all-routers-on-link > multicast address. Note that the subnet router anycast address doesn't > even ensure that the "nearest" router is contacted, which would arguably > have been useful, because the current spec deliberately builds in a > small random delay in responding, to avoid network congestion. > You seem to only looking at it from the point of view of a traffic source being onlink and wanting to send to the subnet router anycast address. The all-routers-on-link multicast address could not be used if the traffic source is off-link. Some scenarios where this might be useful is to be able to establish a BGP session over TCP with the closest router on the remote subnet, or perhaps a GRE or IPsec tunnel with the closest router on the remote subnet. If that router fails, anycast will take care of re-establishing these services to the next closest router without intervention. These scenarios aren't really that special, all you are doing is using anycast to access remote services that just happen to reside on a router instead of a host. > If I have missed some really good use for either set of anycast > addresses, please let me know! > I think another beneficial use of IPv6 (on-link) anycast could be to replace on-link multicast for NTP, reducing the multicast traffic on the segment. The NTP client would send to an anycast address (e.g. supplied via DHCPv6) that all the on-link NTP servers are configured with. IPv6 ND would resolve that anycast address to one of the NTP servers, and after that, all NTP traffic would be unicast between the client and the selected server. If the selected NTP server fails, IPv6 NUD would detect that, triggering another anycast ND address resolution process. Fail over detection doesn't need to be fast in this scenario because hosts run their own clocks (always easy to forget that NTP is a time sync, not a time supply service!), and NTP transactions normally happen only once every 60 seconds or so. There may be other similar IPv4 multicast applications I'm not aware of that could benefit from IPv6's formal anycast capability in a similar way when IPv6 support is added. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
