Joe Abley wrote:
In practice, it seems to me that the way people multi-home these days for client-filled networks is:
1. Number everything internally using private-use addresses 2. Use one NAT per upstream 3. Send your outbound flows through whichever NAT seems appropriate
Very reasonable approach. But, how to choose the proper NAT is still a problem. If there were standard home/site IGP supported by NAT boxes, to which ISPs tell ASPATHLEN as metric, it could help a lot. However, because packets are hot potatoes, ISPs are motivated to tell something larger than ASPATHLEN as the metric, unless they are legally ("MUST" phrase in IETF standards could be) forced not to do so.
There seem to be no shortage of SMB appliances that will take care of this for you without you having to understand anything. The phrase that seems to be used when describing these routers is "dual WAN".
https://www.mushroomnetworks.com http://www.peplink.com/balance/ http://www.tp-link.com/ http://www.draytek.com/
It's trivial to configure this kind of thing on more general-purpose gear too, obviously, but that requires Actual Knowledge of How Things Work whereas these products aim to get things running without any of that.
This style of multi-homing is invisible from the perspective of the routing system.
That is the correct thing to do.
Obviously this doesn't work nicely for inbound connections, but the fact that people do it anyway suggests that isn't a deal-killer
That is a problem MUST be solved by transport (or, at least application) layer of end systems to be able to handle multiple public addresses. It's not very difficult to modify TCP to accept packets with multiple source addresses and send to multiple destination addresses, if the addresses are carried with TCP optional header of SYN and SYNACK packets. Moreover, you can run SMTP and DNS servers with multiple public addresses, because clients are, though at the application layer, implemented to try all the public addresses of servers, even though they are tried only after transport layer time outs.
(presumably every server that needs to accept an inbound connection these days lives elsewhere, in someone's cloud).
It partially because of the current difficulty to have multihoming. But, unless having an entry in DFZ is somehow appropriately taxed, the number of data centers to offer such cloud will increase. The fundamental economical problem of routing table bloat today is that one can multihome with its own DFZ routing table entry without paying anything to all the ISPs and other entities who must pay for enough resources to support the bloating DFZ routing table. Masataka Ohta
I'm not suggesting this is good architecture,
Yes, it is.
I think it's incorrect to insist that the Network doesn't support pervasive end-site multi-homing when it's clear that people are doing it anyway.
Fully agreed. Masataka Ohta