On Thu, 1 Jan 2009, John Leslie wrote:
I'm not at all clear what "support" of "multihoming" Tony is asking
for...
I'm not clear either, because I don't know what mechanisms could make it
work, especially not mechanisms that are deployable.
But what we need is an addressing architecture that allows us to tell the
difference between a hostname that has multiple addresses because they are
required for application addressing, or because the destination has
multiple points of connection. (I think IPv4 vs IPv6 is a special case of
the latter.) This is another way of looking at the id/loc split.
Then there must be a way for an endpoint to make an informed decision
about which of its links to use (source address) and which of the possible
destination links to use. There also needs to be a way to migrate
connections between the available links either pro-actively for seamless
mobility or re-actively for fail-over.
RFC 3484, of course, is "Default Address Selection for IPv6". I
guess that Tony is referring to Section 10.5
I was thinking of the whole thing, actually, because it specifies an
uninformed (therefore broken) version of what I wrote above.
OK, so what is Internet multihoming? If the DNS resolves a hostname
to multiple IP addresses then those are assumed to be multiple links
to the same host.
That is sometimes true, and often not.
Right. My point is that the above seems to be the architectural model, but
actual practice is almost always different.
but the Internet architecture says that the "dumb" network need not
explain its workings to the intelligent but ignorant hosts.
... which seems about right. Layer 3 is supposed to find an
interconnection from one network in the Internet to another. There
seems to be little point in "explaining" how it does this to the
endpoints.
The endpoint doesn't need to know how: it needs to know if a link is
working, or even better, how well it is working compared to the other
alternatives.
Round-robin seems mostly unrelated -- it was never guaranteed to be
particularly good at load-balancing.
True, but it often works well enough in practice and has been widely used
for 15 years. The reason for talking about it is it's an example of a
widespread practice that goes against the architecture. It is not
documented in an RFC and is not supported by the IETF to the extent that
the IETF feels free to break it (in RFC 3484 section 6 rule 9).
A host has no way to use multiple links to provide redundancy or
resilience
This would be nice to fix, but it's not clear there's a sufficient
constituency interested in fixing it.
Almost every bit of portable network-capable consumer electronics has the
hardware to benefit from this fix.
Given multiple addresses for the same hostname, a client has no way
to make an informed decision about which is the best to connect to.
This is why hosts that support IPv6 do not work as well as IPv4-only
hosts.
I guess I don't follow. Indeed, IPv6 hosts that follow RFC [3484]
will defeat some attempts at load-balancing,
This isn't about load balancing. One example is that RFC 3484 prefers IPv6
to IPv4 even when IPv6 connectivity relies on sub-optimal tunnels. Another
is section 6 rule 1 says a client should "avoid unusable destinations"
without specifying any way for a client to find out which destinations are
usable.
There is no support for multiple instances of the same application
per host (i.e. virtual hosting) unless the application has its own
addressing.
I'm not clear what Tony might see as such "support".
Ned's message had some examples. I suppose that SRV records go some way to
fixing the problems with well-known port numbers, so "no support" is an
exaggeration - but we've failed to back-port this fix to older protocols.
There is no support for distributing an application across multiple
hosts (or multiple links to the same host) because address selection
is blind to availability and reachability - whether you consider them
to be binary or fractional values.
Again, I'm not clear.
This is RFC 3484 section 6 rule 1 again. It doesn't work in practice which
is why the real world uses load-balancing routers or anycast or whatever.
Does Tony have an alternative to suggest?
As I said, it was a rant and not intended to be constructive :-) Far
better minds than mine are working on the problem and I'm following their
work with interest - especially whether the proposed improvements to
addressing and routing help with these application-level problems.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
LUNDY FASTNET: EAST OR SOUTHEAST 5 TO 7. MODERATE OR ROUGH. MAINLY FAIR, RAIN
AT FIRST IN FASTNET. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf