John,
JJCK> Of course, multiple A records works, is out there, and have
JCK> worked for years. But they worked better before we introduced JCK> routers (i.e., when the hosts with multiple A records really had JCK> interfaces on different networks). Today, it effectively JCK> implies having multiple addresses on an interface and multiple JCK> "local" address prefixes running around on the same physical LAN JCK> segment.
Multiple addresses is multiple addresses. (I quite the fact that that is grammatical, in this particular case...) Reliability is affected by whether they are through different interfaces and through different network paths, but the degree of host mechanism is really the same.
The fact that the indirection of routed sub-networks is involved is of course significant, but it is merely the cost of scaling. Better, it really is only (did I say "only"?) an administrative cost. Still, the fact that a little more administration gives a lot more reliability strikes me as a fair trade.
JCK> IPv4 was not designed to work well in that environment JCK> and, with at least some implementations that are arguably still JCK> conforming, ... The claim
JCK> has been made that IPv6 _is_ designed to work in that JCK> environment, for whatever that claim may be worth.
I've heard that claim too and have yet to hear it substantiated, although I've asked.
JCK> Perhaps more important, as Noel points out, it doesn't scale JCK> very well, at least in terms of the routing fabric.
Let's see. I get a CIDR network address from one provider. I get another from another. I can have my BGP announce both of them all the time or one of them at a time. I guess I do not see the horrible scaling problem.
Dave:
The scaling problem shows up when you tell the provider of ISP-1 to announce a route for the other address... this effectively becomes a "host route" being advertised....
But of course the whole point is that we don't need this.. at least not with SCTP...and even your proposal which is cloned from add-ip should not require these "host routes"
R
d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>
-- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone)