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@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf