> To be honest, I can't imagine a routing protocol that does anything
> similar to prefix aggregation carrying tags around for individual /32
> or /128 addresses.
It wouldn't have to be for a /32. Take the root servers for
example. Tagging the /24 they each live in would be sufficient.
Similarly for IPv6.
> And while it is conceptually possible to do
> per-packet load balancing, very few routers are actually configured
> that way, because the end station guys complain about the extra packet
> copy load it introduces in TCP. Generally speaking, the source and
> destination addresses in a packet are hashed, the hash reduced using a
> modulus or similar function, and the result used as an index into the
> next hop list in the multipath route. This is done explicitly to limit
> the TCP packet copy issues by reducing the amount of reordering that
> happens in the network. It's legal, but "legal" doesn't make it a good
> thing.
We've pointed this out everytime someone complains about F being
anycast. The problem is that they still argue that this is a
issue. It would be nice to have a come back other that "no one
does this in practice except to demonstrate that it can be done."
> The real issue is temporal. "What is the probability that routing could
> change during the time this address is in use".
>
> Note that none of this about packets going from the anycast server to
> the session originator, which would be the concern that would lead one
> to look hard at packets that had an anycast address as a source. It has
> to do with packets going from the session originator to two different
> nodes offering the anycast service - routing to the anycast address,
> routing changing, choice of server by the network...
>
> What you're cautioning against is the use of an anycast service by an
> originator, not the use of an anycast address as a source.
Yes.
> Do you have any concerns that relate to using an anycast address as the
> *source*?
The classic session problem is when you have a DNS server
cluster (behind a single router) and it is a slave and the
masters are only configured to accept transfer requests
from the anycast address. Lets say that it gets interesting
to say the least especially when the router adds the transport
and / or ports into the mix.
The UDP refresh query will only work for one instance. The
AXFR (over TCP) may only work for another instance (depends
upon how the router identifies a flow). The the NOTIFY message
goes to a instance for which the refresh and/AXFR fails.
Wide area anycast makes this even more interesting.
No, I am not talking about F here. F uses a unicast address
and TSIG for zone transfers / refresh queries.
Getting back to unicast initiated sessions I would still
like to see some mechanism (as low in the stack as possible)
which would allow long running session to survive routing
changes. But if we can't just removing the restrictions
and documenting the problems would be sufficient. Lots of
protocols can cope or can be made to cope as long as short
term sessions work.
e.g.
* HTTP can redirect.
* DNS could return a unicast address as a EDNS option to queries
to the anycast address.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
