> [Keith Moore on a "KMart box"]
> | take it home, plug it in to your phone line or whatever, and get
> | instant internet for all of the computers in your home.
> | (almost just like NATs today except that you get static IP addresses).
>
> No, not "or whatever" but "AND whatever".
>
> Otherwise this is a nice but insufficient device,
> since there is an implicit presupposition that only
> one provider will be used by any given owner/lessor
> of this K-Mart box.
sorry if I oversimplified things. it's clear to me that you have
to allow for user selection of providers, but I was trying to
make a simple illustration of how this might work, not write
the requirements document.
> If one makes a broad policy decision that it should be possible
> and simple for all very small users to be serviced simultaneously
> by multiple providers, then you must be very careful about the
> static IP address constraint.
I'm all for user selection of providers, but 'serviced simultaneously
by multiple providers' seems like a stretch. as I'm sure you are aware,
traditional multihoming has scaling implications for the routing
infrastructure - it's far from clear that it's feasible for every
household to be traditionally multihomed.
my view is that folks who want traditional multihoming
(i.e. they who want their own entries in core routers' tables)
will sooner or later have to pay major ISPs for those entries.
I have heard that you can pay individual ISPs for this now.
so maybe what we need is a clearinghouse organization or two
that provides one-stop shopping - take your money and ensure
that your routing table entry is maintained in each of several
major ISPs routers. once we have that kind of cost recovery model,
folks who really need traditional multihoming (and can afford it)
will be able to get it - it won't matter how big your subnet mask is.
> Traditional multihoming has some significant features:
> -- all the hosts in the multihomed entity have a fixed
> set of addresses relative to one another
> (i.e., hosts don't care about the "remote" topology)
> -- traffic is balanced in both directions in some fashion
> across the set of multiple providers' connections
> -- if there is a partition in the network which
> breaks connectivity through one provider, the
> connectivity will automatically back-up through
> the remaining provider(s) who are unaffected
> by the partition
traditional multihoming is very useful under the right circumstances,
though you need a lot more than just multiple connections advertised
to the net to make it work well.
> Unfortunately, IPv6's current addressing architecture makes it very
> difficult to do this sort of traditional multihoming if one is not
> a TLA. This is a significant step backward from the current IPv4
> situation, where one can persuade various operators to accept
> more-specific prefixes (coloured with appropriate community
> attributes) in order to optimize return traffic from particular
> parts of the Internet.
I agree that traditional multihoming should not be limited to TLA-sized
portions of the net, and I expect that in practice, even in IPv6,
it will not be so limited. having fixed partition sizes in IP addresses
is a bad idea - we learned that long ago with fixed class sizes. And
IPv6-style multihoming through DNS has some fairly significant limitations -
not that it's not useful for some cases, but for many applications it's
not going to substitute for traditional multihoming.
> Therefore, in order to support IPv6 house-network multihoming, so
> as to preserve at least these three features of traditional
> multihoming, either the current IPv6 addressing architecture's
> restrictions on who can be a TLA must be abandoned (so each house
> becomes a TLA), or NATs must be used to rewrite house-network
> addresses into various PA address ranges supplied by the multiple
> providers.
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'
and given the degree of harm that NATs have done to IPv4, I hope they
never rear their ugly heads in IPv6.
> If it is reasonable to want to support multihoming individual
> SMEs, households, or even "smd"s, IPv6's overall addressing and
> routing architecture seems much ill-suited to the task WITHOUT
> the presence of NAT.
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.
> IPv6's larger address space is merely a necessary piece of an
> Internet which will not run out of numbers.
>
> NATs and NAT-like translators appear to be more and more a
> fundamental tool in the IPv6 arsenal, and it unfortunate that
> people position IPv6 as an alternative to NAT.
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.
Keith
