| it's not at all clear to me why households need traditional multihoming,
| nor how to make it feasible for households to have it. so I would regard
| this as overdesign of the home 'internet interface box'
Three observations:
1.
In the past, when and if large arrogant backbone providers like
me used to say that a push against multihoming was a good way
to avoid stressing the current routing system by avoiding
address deaggregation and globally-visible reachable changes
that could result, we would get flayed alive.
that's because (it appeared) you were trying to do this by fiat rather
than simply passing along the costs associated with doing so.
(I can see it now: if you multihome, you pay a charge for every time
one of your links changes state...)
The lesson: always assume that, no matter how technically odd
one thinks it may be, everyone will want to multihome if it is
feasible to do so.
sure, if they can do it for free. but multihoming has costs.
somebody has to pay for it. given that most folks probably don't
need it, it makes sense to let those who need it pay the extra cost.
2.
Multihomed entities like to submit bandwidth increase orders
to one or the other provider over time, depending on a
number of factors. Likewise, singlehomed entities appear
to want to multihome, and at some point rather than upgrade
the single connection to the Internet, will order a second
connection from a different provider, and attempt to do
traditional multihoming.
yep. I don't see the problem as long as they're willing to pay the
ISPs for the routing.
3.
In many areas nearly every household PRESENTLY has several
possible fixed, wireless and switched facilities over which
Internet access can be offered.
sure. but how likely is it that most folks will want to pay for more
than one connection (when one will do), much less having them multihomed?
why would they need that? most ISPs aren't *that* unreliable.
I would say that rather than being overdesigned, that it is slightly
underdesigned, because it does not address the possibility of multitenanted
households, with (for example) his&hers routing policies. (For example,
he uses a cable provider for access, she has a DSL paid for her by her job
so she can do her engineering activities from home).
folks will work out these things just like they work out ways of paying
for trips that are part business and part personal. I'm not convinced
that multihoming is even a distantly likely solution to such a scenario.
| and given the degree of harm that NATs have done to IPv4, I hope they
| never rear their ugly heads in IPv6.
Noel's right, your knees must really hurt!
not as much as my applications do.
| what's the point of traditional multihoming anyway if you have to
| have NATs? you might as well do IPv6-style multihoming - assign a
| separate address prefix to every incoming connection and let the
| hosts sort it out. you don't need NATs to do this.
The NAT function here is subsumed into the host.
no, it's not as bad as a NAT because hosts and applications
can be aware of the multiple addresses if they need to be.
(and those that don't need to be aware don't have to deal with it)
Pushing NATs into hosts is an attractive idea, but it does
require alot more knowledge of the network in the hosts, and
one can gain no economies of scale that a standalone NAT shared
by many hosts can achieve.
I don't see the economies of scale; all I see is the inability of
such a network to efficiently support certain kinds of applications.
| NATs can be a transition tool for connecting between IPv4 and IPv6,
| but NATs should never get in the way of a native IPv6 connection.
They will, though.
I'm sure somebody will do it here or there. But by the time IPv6
gets widely deployed the problems with NATs will be widely understood,
and people will know better than to put them in their network unless
it's being set up for a very specific purpose for which NATs don't
cause a problem.
Keith