Tony Finch <dot@xxxxxxxx> wrote: > > In fact the use of the term "multihoming" to describe multiple IP > addresses on the same link is a serious problem with practical > consequences. I see no benefit of setting up "multi-homing" without separate links. Routing based on source address is a dangerous practice, even when the source address is trusted. > The Internet's idea of multihoming as supported by the architecture is > NOT what I consider to be multihoming. (The lack of support for my > idea of multihoming makes Internet connections klunky, fragile, and > immobile, but we all know that, and should be embarrassed by it.) I'm not at all clear what "support" of "multihoming" Tony is asking for... > The Internet's idea of multihoming is reasonably precisely > encapsulated by RFC 3484. This specification breaks existing practice > and fails to do what it is designed to. RFC 3484, of course, is "Default Address Selection for IPv6". I guess that Tony is referring to Section 10.5 (which, frankly, I have never succeeded in deciphering). If anyone actually does what 10.5 suggests, I have not stumbled upon it. > 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. We indeed do that in a few cases, to have a path which bypasses routing or connectivity problems. More often, we use separate DNS names to point to the different interfaces on the same host. Typically, multiple A)ddress records for the same domain name will point to different hosts configured to return identical responses to service requests. > Unfortunately there is no way for a client to make an informed > decision about which IP address to choose. Our attitude is that clients _should_ be expected to choose blindly. > RFC 3484 specifies how to make an UNINFORMED decision, or at best, > how one could in principle inform the decision. However in order to be > informed, a host needs to be hooked into the routing infrastructure - > 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. > As a result, having multiple addreses for the same hostname on > different links does not work. There's some logical inference missing here. It certainly does work, though presumably it doesn't do something which Tony thinks might be expected of it. > It never worked before RFC 3484, and though RFC 3484 tries to fix it, > it fails because of the lack of routing information. I don't follow... > What is worse is it breaks DNS round robin - which I admit is a hack, > but it's a hack with 15 years of deployment, therefore not to be > broken without warning. Na?ve implementations have broken round-robin > DNS because RFC 3484 ignores it. Round-robin seems mostly unrelated -- it was never guaranteed to be particularly good at load-balancing. > So to summarize: > > A host has no way to use multiple links to provide redundancy or > resilience, without injecting a PI route into the DFZ - like the > anycasted root name servers. This would be nice to fix, but it's not clear there's a sufficient constituency interested in fixing it. > 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 3483 will defeat some attempts at load-balancing, but it would seem that this would only affect server farms using IPv6 -- which ought to know better than to depend on those load-balancing tricks. > The Internet addressing architecture has a built-in idea that there > is one instance of each application per host, and applications are > identified by protocols (port numbers). This is a broken idea. It should be abandoned. > 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". > 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. > If you try to use it you are either relying on the non-kosher > round-robin DNS, or you are likely to suffer failed or sub-optimal > connections. RFC 3484 specifies that implementations of getaddrinfo() should sort the list of IPv6 and IPv4 addresses that they return. (This has never seemed to me a particularly good idea.) It goes on to state that applications should iterate through the list until they find a working address. (This need not imply a delay, as I read it.) > In practice multihomed services (services with multiple redundant > links to the public Internet) do not use any of the techniques > described in RFCs as host multihoming, and often use techniques > that are contrary to the architecture or outright protocol > violations (e.g. Akamai's use of CNAME chains). Does Tony have an alternative to suggest? -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf