Noel Chiappa wrote:
> From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
> The costs aren't just getting pushed to the multihoming site, because
> the software that has to deal with multihoming isn't just distributed to
> those users. The costs are getting pushed on to software developers,
> and from there, to everybody who uses IPv6 software
This seems to me to be like complaining that support for multiprocessor
machines in Windows, Linux etc is pushing costs onto people with uniprocessors
workstations, because there's extra OS code to handle multiple processors, and
the software that has to deal with multiple processors isn't just distributed
to people with multiprocessor machines, etc, etc. Would not the same argument
also apply to encrytion, Mobile6, and a whole other list of 'mandatory'
it might. but I wasn't talking about those cases. and I'd also suggest
that trying to use one mistake to justify another is neither valid logic
nor sound engineering.
(also in the case of multiprocessors - given that nobody has figured out
a way to make single-core CPUs clock faster while still keeping them at
temperatures at which they can operate, one could argue that the
uniprocessor's days are numbered anyway. though I'm not one who
believes that everybody's CPUs have to keep getting faster.)
> Contrast this with an approach that says: "... all of your inbound
> traffic will be routed through one of a set of aggregators that hide
> your real (PA) prefies and link transitions from the rest of the
> network, and which tunnel ... your traffic to you over one or more of
> your PA prefixes. ... *That* approach would put the costs squarely on
> those who benefited.
That's certainly viable, and it doesn't depend on deployment of any new
"stuff". However, I have to wonder why this hasn't happened already.
I'm guessing it's because:
(a) we are more comfortable using skills that are familiar to us (e.g.
writing code and building hardware), than we are with trusting other
people with different skills to use those skills (like setting up
stable, trustworthy organizational structures and fighting political
(b) we know from some experience (such as that with ICANN) that central
points of political control can make for considerable nastiness. in
comparison, deferring to some unsolved _technical_ problem seems safer
to us, even though it's unsolved ... partially just because we haven't
been sufficiently burned by that kind of problem yet, and partially
because we inherently trust technical people more than we do politicians
or organizational structures.
however I don't think we should entirely discount a solution that relies
on those skills.
Ietf mailing list