Noel Chiappa wrote: > > From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > > > 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' > components? 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 battles). (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. Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf