Re: The internet architecture

[Tony Finch <dot at dotat.at>]

On Tue, 30 Dec 2008, Michael Richardson wrote:
> Tony Finch <dot at dotat.at> wrote:
> >
> > The kind of multihoming I am talking about is where you are
> > using multiple links for redundncy or resilience - i.e. the
> > same reasons for site multihoming.
>
>   I think it says something to the extreme *rarity* of host multihoming
> (for systems that initiate connections) that there is even this confusion.
>   You can be multihomed with one physical interface.

NOT in the sense that I am talking about.

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've been asked twice now in private email to clarify what I mean, so this
is going to turn into a massive rant about how the current Internet
architecture - as it is deployed, and as it seems to be developing - has a
completely broken idea of how to address endpoints. The multiple meanings
of the word "multihoming" relate directly to the multiple points in the
rant.

> This is rather more common for machines that mostly accept connections
> (web servers), as you can do relatively simple source address based
> policy routing.

In my experience policy routing is not what people use multiple addresses
on the same link for. Multiple addresses on the same link are used for
virtual hosting for application protocols that don't signal
application-level addresses within the application protocol. The canonical
example is HTTP over SSL, but POP and IMAP have the same problem. (People
sometimes hack around this design error in POP and IMAP by embedding the
virtual domain in the username, which is yet another example of why every
application protocol needs its own addressing architecture.) To
re-iterate, one computer providing multiple different services on the same
IP address is NOT multihoming, in the same way that one computer providing
multiple services on different port numbers is not multihoming.

The dual scenario is multiple computers providing the same service on
different IP addresses. The simplest deployment is to scale up on the
cheap by relying on round-robin DNS. In this case there are multiple
links, but they are often on the same layer 2 segment, so again not
multihoming in the sense that I meant. If you scale up further, the first
thing you do is get proper resilience with a load-balancing router (which
probably requires the architecturally impure NAT). If you require more
than one point of presence, the next step (beyond layer 2 techniques like
trunking ethernet vlans between multiple sites) is IP routing tricks, i.e.
anycast. For serious wide-area services, you are likely to use location-
and availibity-sensitive DNS to deirect users to the right instance.

Note that NONE of these techniques use the architecturally-supported idea
of multihoming. In fact most of them deliberately avoid it because it does
not work!

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.) 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.

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.

Unfortunately there is no way for a client to make an informed decision
about which IP address to choose. 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.

As a result, having multiple addreses for the same hostname on different
links does not work. It never worked before RFC 3484, and though RFC 3484
tries to fix it, it fails because of the lack of routing information. 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.

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.

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.

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). There is no support for multiple instances of
the same application per host (i.e. virtual hosting) unless the
application has its own addressing.

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. 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.

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).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FORTIES: NORTHERLY 4 OR 5, OCCASIONALLY 6 LATER IN EAST. SLIGHT, BECOMING
MODERATE OR ROUGH. SHOWERS. MAINLY GOOD.

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf