Hang on a second, I'm sure those goalposts were over here a minute ago.:-)
You're right, there are barriers to deployment of IPv6 (film at 11). That's why you're seeing the most take-up at the moment in the academic networks, at least in the western world (as noted elsewhere, the far east are WAY ahead of the rest of us in IPv6 deployment). We're working out the bugs and creating the initial installed base in advance of people going commercial with it and actually making money out of it.
This is proper order - if the commercial guys were in first, wouldn't you wonder what the hell the research networks were for, anyway? Give it time. (Oh, and creating customer demand wouldn't hurt, people, thanks!:) ).
A long time ago, we had a network. It was quite good. It was the phone network. It was great, but it carried voice traffic, and not a whole pile else.
Some bright spark had this notion of packet switching, and it caught on. It's like this - once you deploy the packet switching network, the telco is no longer the arbiter of what applications are run on it. You are. You can run a mail server, I can run NNTP, and some maniac over there is writing something called a Web Browser.
The innovation that made the internet what we know today came from the fact that any idiot could develop a protocol, not just a telco engineer.
Now, cut forward. We have an internet, but we're kind of short of address space, so we use a lot of NATs to conserve them. What's going on here? Well, I can use a sensible TCP application, but that's about it. If I want to run some crazy app that needs Multicast, or an instant messenger, or something that just doesn't get on with the TCP congestion algorithm - well, not only do I need the permission of my network security team (which is good and proper) - but I need support from the NAT box.
The NAT box needs to support my protocol, which might not even exist yet. You want to talk about chicken and egg?
And innovation stops. There's a lot of talk of the end-to-end principle and handwaving and that, but that's the meaning - there's no more innovation.
NAT is not a security policy. It's a means to conserve addresses. It has an added feature that prevents you connecting directly inward to hosts on the network - but so does a stateful firewall. The point of compromise is exactly the same. It's rude to use global IP space behind a firewall like that in IPv4 land, but only for purposes of conservation. In IPv6, that doesn't apply.
I'm not claiming that IPv6 is going to solve all these ills - but NAT is a bigger hassle than you give it credit for. A prerequisite for solving this is having mnore address space. We'll tackle the rest in good time.:)
The biggest problem is that none of the primary routers support it.
Sources please!
*cough* two core routers dual-stacked where I work, one scheduled for next wednesday, the rest to follow in the weeks following. Abilene supports IPv6 natively. CA*net supports IPv6 natively. SURFnet supports IPv6 natively. IPv6 traffic exchanged at LINX and AMSIX. NTT Europe launched commercial IPv6 service in Europe on 19th February.
Btw. Any chance you could ask your ISP for IPv6 connectivity? From your post it sounds like they could do with some customer demand.:)
3FFE::/16 is the experimental 6bone space, where you try out allocation policies before settling on a real one. They've settled on a real one. Even better, it's the same in allthree (er, four) regions. The 6bone's purpose is fulfilled , we're in production mode and, as was always intended, it's time to think about retiring it.
How many times: IP address don't cost money. Sure, the RIRs charge for the service of allocation, and your ISP is entitled to charge for the services around them. They do their job pretty well, and with consensus of the community (a rarity in this day and age). Great as Bob Fink is, do you really want to continue trusting address allocation to one guy as a volunteer project?
You get addresses from your ISP.
You get addresses from your ISP.
You get addresses from your ISP. There are loads of them. If you need them, you can have them. The expense is not in getting the damn addresses. "Experimental" does not mean "free". "Production" does not mean "business".
AftanGustur: IPv6 is not a bastard protocol, routers don't need to fragment anymore, and the IETF is not working on a new damn protocol. You don't cite any sources, so I can't refute it. Please do.
Guys, there are a lot of misconceptions about IPv6. I appreciate this - it's not an intuitive subject, and it's possible to believe you know a lot more about it than you actually do. But, the details are there. Please do the reading and start asking your ISP for connectivity. No, your real ISP. There are people out there who want to deploy this, now, and we're waiting for customer demand. Go nuts!
I guess what you want to know is why your charge increases per bandwidth consumed rather than just a list of the various expenses ISPs incur (which other people have covered pretty well), which theoretically could be dealt with by a flat charge. Here's my understanding of that. Some of it's outside my area of direct expertise - I'll mark the point where we hit that.
As the bandwidth use in an ISP increases, the overall quality of service provided to its customers goes down (i.e. contention increases), until the ISP does the following:
Upgrade their external (upstream) links (more on this in a minute)
Upgrade their internal infrastructure (which might also be telco links between cities or countries, or might be 10M hubs going to 100M or Gigabit Ethernet switches)
Upgrade their supporting infrastructure (proxy caches, mail servers, billing systems, people on the tech support line, abuse department - this last one is a problem that seems to increase exponentially with size)
You're probably already familiar with the difference between server hardware for 100 users and hardware for 10,000. Switches and routers tend to be a step upgrade; they work fine for three years then BANG you need to spend forty thousand euro, and that'll do you for another three years, or whatever.
Telco bandwidth costs money, and upstream ISP service over that bandwidth costs more. The increase in that is usually sublinear - 4Mbps costs a little less than 2*2Mbps, 8Mbps costs a little less than twice that. The reasons for those costs are where I start to leave the stuff I do for a living, but my understanding is this.
For internet service (this is different and separate from just getting a leased line!), the same principles as above apply, just on a bigger scale. The larger bandwidth user takes a larger chunk of the provider's resources, therefore they'll (within certain parameters) get charged commensureately more.
For the cost of the leased line itself:
It costs money to put fibre in the ground, or under the sea, or whatever, and that needs to be recouped. This is a once-off, and it takes ages to pay back (hence the massive debts that the Worldcoms of this world are operating under).
The equipment that goes at each end of the wire costs a fuckload. At really high speeds (10 gig and thereabouts) it could cost more than the fibre itself. This isn't quite a once-off, but is a step upgrade a bit like your own switch infrastructure.
People and systems need to monitor the network, work out what bits have broken and need fixes, what's just had a digger put through it, etc. etc.
That, of course, is without all the associated costs of running a business with more than two people in it, which are (to put it politely) non-trivial.
I hear you, and I definitely appreciate what you're trying to achieve. However, before you launch wholesale into such a world, I would ask you to consider this.
Believe it or not, the object of ICANN was to try to create a body that could succeed IANA and continue to allow us to make the decisions that needed to be made through consensus - the way we'd been doing it all along. The "rough consensus and running code" attitude of the IETF and other groups is what has turned out the useful stuff on the internet today - little things like TCP, SMTP, DNS - stuff like that.
If you "fork" ICANN, as it were, this is means a couple of things. One is that it's tantamount to an admission that consensus based decisions can't be made at this scale. Whether true or not, this would be a great pity IMO, and I'd like to see every avenue exhausted before we abandon such a great system for something less effective (like, say, democracy - something which is damn good, but despite best efforts seems to leave some people feeling a bit left out).
Also, when people are forced to make an exclusive choice, there is no guarantee that the "better" choice will win (FSVO "better" - cf. Betamax, Apple, etc etc). Further, if such a choice is forced, you may assume that the number of competitors will not remain at 2, and that some of the choices will be particularly powerful bodies that might not have the best interests of the network at heart.
If DNS names were no longer universal, do you assume that all browsers would continue to use DNS for lookup? What if they instead implement their own keyword search as a preference (perhaps giving free 1-year keyword licenses to all domain holders as of $DATE) so that "our customers get a consistent experience"? Might they succeed? If they did, would that be a positive thing?
Working within the system is often boring and frustrating. However when you are railing against perceived corporate takeover, remember how our actions, regardless of anyone's intentions, might give a company the opportunity to exercise their own "corporate takeover" at another level. It is absolutely within your rights and within your means to propose an alternative root. However, there is much to be lost by such a move, and there is much to be gained by, at least, trying to follow the backwards-compatible path until no other option remains.
ICANN stands for "Internet Corporation for Assigned Names and Numbers". It is a non-profit set up a few years back to take over the duties of the Internet Assigned Numbers Authority.
One of these is the clerical duty of assigning/8 blocks of global IPv4 address space and/16 blocks of IPv6 address space to each RegionalInternetRegistry as needed. The users of the address space decide policy, and it's this policy that the RIRs implement.
Another duty ICANN took over is maintenance of the DNS root (which has been the controversial part), and a third duty is maintenance of the list of protocol numbers (imagine a link to your/etc/services just here - something's stopping me posting triple-slash).
But if you look at the IP address and nothing else, you can't uniquely identify the data coming back in order to cache it. Even if the packet is sent to the IP address you specified, the proxy must identify the HTTP query in order to store or pull the appropriate document from the cache. After all, a single IP address can serve multiple pages, never mind multiple virtual servers:-)
I guess you could rewrite the cache to store pages based on a [http request,ip address] pair, but that's going to cause, at best, a performance hit when dealing with any large multiple-IP site (the very kind of sites we want to cache; don't even start about Dynamic DNS), and is a substantial change to the behaviour of a HTTP proxy.
That's a lot of effort to put in in order to get a performance hit. I submit that the correct way to solve this problem is for the industry to agree on a common DNS root.
I see what you mean. You are sending traffic to a particular address based on your own DNS resolution, and if the traffic is proxied, you want it to be sent to your chosen destination, not that of the proxy.
In my opinion, the ISP is exhibiting correct behaviour.
Picture this: the object of the exercise with the transparent proxy is to cache pages and increase speed for the customer, right? I think it's already been agreed earlier in the thread that this is not entirely evil.
Let's say the proxy honours the destination IP address that you chose (I'm not sure how this would work in practice, but I'll go with it for now). It returns the web page from the server that your DNS picked, and caches it for the next guy.
Another customer requests a page with the same name. What if they're using a DNS root where the answer conflicts with yours? The customer gets the "wrong" web page. Because cached objects eventually expire, this means that the customer might get a completely different site dependent only on the time and date they happened request it.
The ISP doesn't use the same DNS root you do, so they can't begin to troubleshoot the problem.
I concede that the popular "alternate" DNS roots have few enough conflicts with the IANA-assigned roots at the minute, but even that is an irrelevancy - any solution that allows a customer to choose destination IP address on behalf of other customers opens up the ISP to a denial of service attack by a user less trustworthy than you or I. One could set up an arbitrary "root" server that resolves www.yahoo.com to my own site. Or google. Or some site that accepts credit card orders.
I can't see any scalable way out of this without the ISP picking one root, and sticking with it. If that is so, then I think this is a fundamental problem with split roots and, if you really want to use them, be fully aware of what you're getting yourself into. Turning off the transparent proxy will help this time, but you won't be able to rely on being able to talk to any server on the internet that doesn't use the same root as yours, even the servers you don't (usually) need to know exist.
Same here, but I'm just on cover from home, and I volunteered for it.
Christmas is always very quiet, except the last couple of years where we had some pretty ugly weather and it knocked out power to a few places, but that's about it. My boss is fond of quoting that 80pc of network outages are caused by network engineers doing things. At Christmas, when no one's doing anything, everything's stable!
So I spend Christmas with my family, logging on occasionally, unlikely to get called in. And I get to take off out of the country for New Year while someone else takes the reins.
Not a peep so far, and I fly to Scotland on the 27th...
Without debating the whys and wheres of the rest of your post, let me take issue with this statement:
Now, whether or not BGP can keep up with all the updates is a different story. But with the vast amounts of bandwidth between core routers and GHz processors cheaply available, I think a box could be built to handle it.
See, you've just fallen into the exponential trap. Take a look at this:
Assertion: The biggest cost in internet routing is not the size of the routing table (==RAM).
Assertion: The biggest cost in internet routing is the quantity of updates to the routing table (==CPU)
Assertion: The rate of increase of updates to the routing table is greater than Moore's law
If these three statements are true - and I think they are easily verifiable - then...
Conclusion: The rate of updates to the routing table is growing at a faster pace than CPUs can be built to keep up.
...and alternate methods must be found to solve the problem.
The internet was supposedly designed to route around points of failure, however this is now only really true of the 'core' of
the internet - As it grows, it becomes less and less robust, since routable IPs are no longer available to people who need less than (or can't afford to pay for) a/19.
BGP multihoming with provider independent address space is not the only way to take advantage of the resilience of IP. For one example in one situation, a customer can multihome (with physically diverse leased lines of course, right?) to two different PoPs of the same ISP, and route their PA space appropriately.
The advantage of this is that it doesn't require every core internet router to be aware of the multiple paths to your network; I have multiple paths to your ISP already, and they handle the resilience from there. This speeds convergence time for you (you don't want to wait for routers in US, Europe and Australia to all catch up with your flapping lines, do you?) and reduces the cost to me of maintaining a full routing table.
Address space is allocated based on how many addresses you need. Routability of small allocations isn't some grand conspiracy; it's a decision resting with each network based on just how costly it is to maintain a copy of the global routing table.
And while increasing the available address space is definitely a good thing, extra address space, as you say, won't solve that particular problem. However if the rate of growth of BGP multihomed networks is greater than Moore's law, neither will simply slapping extra RAM and CPU into backbone routers. Eventually the routing table will outstrip affordable router capacity and you will reach the same problem from the other direction.
IPv6 has some neat tricks that might actually reduce the dependence on BGP multihoming. In the meantime, consider the hassle of BGP multihoming for you, and see if there isn't actually another solution that fulfils your requirements better - there might not be, but you might be surprised.
Dave
[My opinions, not necessarily those of my employer]
Damn good response. There is a lot to think about in there. To respond individually will take time (I'd be glad to do so in email if you wish) and I think this story will have dropped off the front page by the time I'm done, so with your permission I'm going to concentrate on this:
You struck a nerve there. Do you REALLY think that the Internet and DNS are not going to evolve over time? I respect your opinion, don't get me wrong, but I really disagree here. As I've said before, the existence of alternatives alone just proves that there is a problem with the way DNS is being managed. And about ICANN standing between us and a corporate takeover - I'm really having trouble holding myself together on that one. A corporate takeover? Of what, DNS?!?
I think this is at the centre of our differing opinions. Yes, I think the internet needs to evolve. No, I don't think you're doing so in the right way.
I like how the internet has evolved over time. I think it's fascinating to see a system built on real consensus come so far and overcome so many obstacles. I think it's amazing; there are lessons to be learned here in how we live the rest of our lives.
I don't think alternate roots are a part of this process - not yet, at any rate. DNS is a rigid hierarchy, and as a result, it's brittle. Conflicts must inevitably arise as we are beginning to see with the alternate.BIZ domains. I think this undermines the usefulness of DNS, and since we have never had to live with an inconsistent DNS before, I don't think the potential consequences are clearly understood.
I can't buy your assertion that DNS can never be replaced with proprietary solutions. These guys are masters of embrace+extend. It wouldn't happen overnight, but the prize of dominance is high - you become the de facto DNS replacement.
If this were any other protocol, big deal. But DNS is fundamental to the internet. When someone reports a network problem, it is the one thing I always check first, because it's the one ubiquitous protocol. I believe that:
If you own 90pc of named.ca files, you own DNS
If you own DNS, you own the internet
It is not yet necessary to hand that to someone else
I've been told "don't hinder progress" a lot. I've seen it used to justify everything from HTML news posts to.DOC as an email standard. That alternate roots exist is not just an indication that there is something wrong with the current system; I think it's a tragedy. But of all the alternate people who could hold the root - and in a world of 90pc Windows desktops, I do believe there'll eventually be only one root that matters - I have more faith in ICANN and its structures to ensure the continued life of a consensus-built net than I do anyone else.
There's been a lot of frustration at ICANN I think because of the appointed directors. That is changing. Much of the board is different, and what's left are also changing. The At Large directors are taking their seats, and more will be elected (it won't be limited to five as previous slashdot stories may have had you believe). There are a lot of good people on that board now, and not just on the At Large side.
And if we shouldn't give those guys a chance at making it work, who the hell else should we trust?
Your reasoning is excellent, Chris, and I wish I could be as optimistic as you. But I fear that in the root DNS we have encountered one of the potential vulnerable spots of the whole internet, and right now I do not wish to take the risk of breaking it.
You're right, there's a fair amount of power wrapped up in the various slashdot readers. And this slashdot reader sure as hell won't be joining you in your protest.
I know it's trendy to slag off ICANN. I know everyone has their problems with it. I know everyone feels like the only thing they can do against this new authority is to shout about it, or to "rebel". And in that context, splitting the root seems like a fantastic idea.
Don't do it, guys.
Internet "precendent" says that we've tried to work out problems through consensus building. Seriously! We get together in groups like RIPE and NANOG, present our ideas, and try to build consensus. We can fork, yeah, but we fork as little as possible, because when we fork, we split the user base and we are all weaker because of it.
But that's not the worst of it in this case.
Ever since domain space became valuable, there are so many special interests circling it that it's not funny anymore. It's pretty ugly, actually. Consensus building has been pretty impossible because people with dollar signs flashing in their eyes shout louder, and the people who are just plain kooks shout the loudest. That's hurt a lot of the development of DNS in the last few years. The one weapon we've always had against this is caution, and a recognised authority.
All those special interests are sitting, eagerly awaiting the day when a significant majority of admins reject ICANN and switch to another root.
When that happens, they'll turn on each other, and that's when it gets ugly.
You think you have user problems because people think that "The Internet" is the thing behind the button on their Windows desktop? That's nothing compared to what we (all of us) will have to deal with if we split the root.
I'm speculating now, but here's my guess. See what you think:
ISPs will start advertising which of the conflicting roots they prefer: "We serve ICANN names!" "We follow AlterNIC!" etc. etc.
Users won't understand a word of this
Users will complain "Why can't I reach mysite.biz!"
Lawsuit free-for-all over misleading advertisements and broken SLAs
Lawsuit free-for-all over conflicting trademarks
AOL, Microsoft and some others will remove DNS access from the user (URL bars, email addresses, etc) and replace it with a directory system that they manage (keyword searches, address books). One of these will gain a monopoly. No one but slashdot readers will care.
Don't be fooled into thinking that everyone pushing for alternate DNS has the good of the internet at heart. Some of them mean well, I'm sure. Some of them are sound guys. I'm equally sure that some of them are out to grab a piece of the gold mine that is DNS, and are willing to damage it in the process. Believe it or not, ICANN is the one thing standing between us and a corporate takeover of the internet.
Yeah, I just wrote that with a straight face. I mean it.
To drag this back on topic? We're seeing the beginning of this now. Everyone's been bitching at ICANN to hurry up and introduce some new TLDs already (watch for buzzwords such as "artificial scarcity" in other slashdot posts near you!) What happened? Someone tried to preempt them and lured a some-thousand userbase to give themselves some credence. What do ICANN do here? Reject potentially better-prepared proposals for favour of this one? I don't think that's fair.
Guys, you really should know better than to measure something's worth through the count of its [slashdot|newspaper] headlines. Jon Katz had this one nailed down years ago. A lot of the criticism against ICANN is genuine; a lot of it's crud; and a lot of it ignores the best interests of the internet.
Think for yourselves. Don't be afraid not to fork.
Russ Cooper just posted a more educated summary of the problem to NTBUGTRAQ. It's in the archives at this location.
It's NOT as bad as first reported. Russ says that his comment that it affects "almost every web hosting provider" was based on the info that it was some sort of Front Page issue. It's not that simple, and it seems that it's only exploitable by users who have already been granted web authoring permissions on the box.
If you want to create a second way in, man, go ahead. Write a CGI script to exec sshd or something. But you don't need the maintainers of Apache to do that for you; you don't need that capability hidden from you; and you sure as hell don't need that capability being discovered in someone else's system on the other side of the globe and then exploited in yours while you are taking your first holiday in 2 years...
Backdoors, done properly, have their place. That place is not implemented unknowingly in thousands and thousands of installations worldwide where such a backdoor would be wholly unsuitable anyway.
Make no mistake. Whatever this is, it's not a feature.
Say due to some "bug" in the software, you get locked out of your mission critical system. How do you get back in?
You send a tech to let you back in through a well known and documented procedure that allows full access from the console, a feature you knew about and chose not to disable.
The fact that backdoors can be useful does not excuse one being placed silently in a piece of software that is then marketed as secure. You may approve of having a remote back door; you may believe that the risk is sufficiently small to justify the potential cost savings. That's great. But that is a decision for each customer to make, and not every customer will agree.
Separately, it's my opinion that a common remote backdoor, no matter how well hidden, will turn round and bite you on the arse eventually. This software is too well deployed; too many people are auditing it and probing it. If an engineer puts 100 hours of work into hiding it, it only takes 100 people 1 hour of searching to equal that effort. How before someone makes that discovery? And how long after that before it is widely reported anywhere other than IRC?
I'd really appreciate if you could ask the WAVE people how they plan to deal with its potential as a tool for bullying.
WAVE strikes me as an easy, anonymous and rewarding ($$$, t-shirts) way to cause instant grief to a fellow pupil. Kids who are willing to break a kid's bicycle lights, ostracise her in the yard, or embarrass them in the classroom on a permanent basis, will have no qualms about abusing this company's tool to get anyone quiet or different into trouble.
Now what I suspect is that, further to the above, the company's mechanisms will not be sufficient to catch such abuse.
Remember Independence Day? Remember the drunkard pilot who dusted the wrong field? Remember the TV interview with his "friends" who said, "Nice guy. Harmless guy. But the aliens abused him. Sexually."
Picture this now: an anonymous tip is received, "this guy's trouble". The class is identified. Now I don't know what WAVE's procedures are, but I reckon they're not going to just use a single anonymous tip-off before hauling in the kid, right? Surely they'll interview other kids first to make sure it's not just a grudge thing?
In a class of thirty, you will get twenty-four people who say "Dunno. He's quiet all the time. Noone seems to like him." and five who, for the laugh, will make up half-truths for the interviewer to make the kid seem as disturbed as possible.
Interviewer files his report, which is processed and added to the statistics database that will be presented to customers at the end of the year saying "we dealt with 100,000 potentially distressed students this year".
It's easy to see the individual elements of WAVE as pretty harmless in themselves. But taken together:
Profit-making institution
Anonymous reporting
Rewards of cash and clothing
Profit-making institution (this is what bothers me most, can you guess?)
...they'd seem to be the ingredients for a positive-feedback abuse loop. How can the WAVE people ensure that that never happens, please?
The other comments about rsync et. al. are spot on for replicating (rsync is great), but they don't address the problem of authority; if a file exists on a particular server, is it new (so replicate) or old (so delete)?
I think you need an upload procedure to get around that. Try this:
Restrict uploads to a particular "upload" directory, on every server.
Wait for a file to be uploaded to this dir.
Use a separate rsync to copy this file to the appropriate place on the nominal master server
Use your regular rsync to synchronise the mirrors with the master.
There are a couple of issues with this, but you can get around them with a little added complexity in your uploading-to-master algorithm. If the master server goes down then it's true, you can't update; but the master doesn't need to be static, it just needs to be consistent. If uploads are that critical, you can use another protocol - say DNS? - to designate an arbitrary server as master.
Inktomi, last I looked, don't run a search engine site; they develop the tech and license it to others who get involved in the messy business of making a popular search engine site.
IIRC, their highest profile customers are Hotbot, who used Inktomi from the start, and Yahoo!, who switched from Alta Vista to Inktomi. Inktomi is a more neutral backend for Yahoo!, who are competing in the same market as Alta Vista.
Right. Burn 'em at the stake? Let's see why again?
I can tell you right now @Home does NOT scan anything except for...
They didn't say they did. They said they will.
Secondly, @Home has, at the time of this posting, not scanned the subnet *I* am on for anything on port 8000, or 8080
Lastly, @Home customers rarely run proxies. I have scanned port 8000 and 8080
Right, I just don't get this. Do you know how long a scan takes? I'm not talking a script kiddie's nmap for open ports. I mean systematically probing an entire network for a stated behaviour with a sufficient timeout that you won't miss really slow servers (like, oh, say, ones that are already pumping piles of spam). They announced they'd start this as of today. Clue: it's not done yet.
And what do ports 8000 and 8080 have to do with this anyway? Are you talking about web proxies? They're a problem, sure, but tell me again how scanning for web proxies will get @Home out of the UDP? Can you even tell if @Home is scanning you on the NNTP port?
Also - @home has a strict AUP *against* security scans.
Heh. Gotta love the way you admit breaking your own ISP's rules on a public forum. And there are ways to judge relative security of an ISP. "I've run lots of scans and not been busted yet" is not one of them.
Signal 11, and everyone else, stop jumping on people when they admit they have a problem. This is good. @Home are doing the right thing when they admit this. It is the vital first step without which no further action can be taken. I know it's tempting to scream and roar at someone because they're evil, or because they snubbed you in the past. But these same people that are evil or snubbed you are the ones that we most need to take this step.
Please. If you think you can challenge @Home's statement, forward your evidence to the UDP people so they can consider it properly (clue: slashdot is not the best place to do this). But every time I see someone taking that first step and being met with ill-informed cries to burn, let 'em burn, I have to ask myself if I can actually ask the next guy to take it in good faith. I'm rapidly coming to the conclusion that I can't.
The announcement was a little quick off the mark - binaries are due to be posted within the next couple of hours - but Mozillazine (great site) has news of M12 binaries for Solaris and RPMs for Red Hat
The speed at which Mozilla has come along recently is something else. If this isn't alpha, then it is damn close. Download, enjoy, and report those bugs!
Dave
--
Re:Funny how the system fails to work both ways
on
ESR talks in Dublin
·
· Score: 2
[Discl: I know nothing about BSD, and less than I ought to about Linux devel. Below is a misquote of what I heard on Thursday. Feel free to correct.]
Do the *BSDs also fall into that category now?
He got called on that one. There were a fair number of BSD followers in the audience. (And someone selling BSD CDs at the start...)
His point was that BSD has one really nice feature that's gorgeous on the surface but has a huge hidden cost. One make can build the whole system.
This is really good - but it's brittle.
If you submit a patch to Linus, and it's rejected - it's a patch, it's not too painful to apply manually, and it's not too painful to keep up to date. This, and the general taboo against forking, help keeps Linux moving in one direction.
However, if you submit a change to one of the BSD development groups, and it is rejected, then because you have to fit it into this huge, single structure - it's actually easier to clone that structure and spin off in your own direction.
He was pressed further, and in the end, everyone was right - the BSD people made good points about BSD (the userland is the same), and Eric and others made good points about Linux (the kernel is the same).
But I don't take your point about FUD. He doesn't like the look of Win2K - fine. But that doesn't invalidate his arguments. He has sound philosophical reasons for his beliefs, the condition of W2K does not invalidate those reasons. Unless W2K works miracles, it's possible that it may bear them out.
Slashdot Mirror
Hang on a second, I'm sure those goalposts were over here a minute ago. :-)
:) ).
You're right, there are barriers to deployment of IPv6 (film at 11). That's why you're seeing the most take-up at the moment in the academic networks, at least in the western world (as noted elsewhere, the far east are WAY ahead of the rest of us in IPv6 deployment). We're working out the bugs and creating the initial installed base in advance of people going commercial with it and actually making money out of it.
This is proper order - if the commercial guys were in first, wouldn't you wonder what the hell the research networks were for, anyway? Give it time. (Oh, and creating customer demand wouldn't hurt, people, thanks!
Dave
Let me put it this way.
:)
A long time ago, we had a network. It was quite good. It was the phone network. It was great, but it carried voice traffic, and not a whole pile else.
Some bright spark had this notion of packet switching, and it caught on. It's like this - once you deploy the packet switching network, the telco is no longer the arbiter of what applications are run on it. You are. You can run a mail server, I can run NNTP, and some maniac over there is writing something called a Web Browser.
The innovation that made the internet what we know today came from the fact that any idiot could develop a protocol, not just a telco engineer.
Now, cut forward. We have an internet, but we're kind of short of address space, so we use a lot of NATs to conserve them. What's going on here? Well, I can use a sensible TCP application, but that's about it. If I want to run some crazy app that needs Multicast, or an instant messenger, or something that just doesn't get on with the TCP congestion algorithm - well, not only do I need the permission of my network security team (which is good and proper) - but I need support from the NAT box.
The NAT box needs to support my protocol, which might not even exist yet. You want to talk about chicken and egg?
And innovation stops. There's a lot of talk of the end-to-end principle and handwaving and that, but that's the meaning - there's no more innovation.
NAT is not a security policy. It's a means to conserve addresses. It has an added feature that prevents you connecting directly inward to hosts on the network - but so does a stateful firewall. The point of compromise is exactly the same. It's rude to use global IP space behind a firewall like that in IPv4 land, but only for purposes of conservation. In IPv6, that doesn't apply.
I'm not claiming that IPv6 is going to solve all these ills - but NAT is a bigger hassle than you give it credit for. A prerequisite for solving this is having mnore address space. We'll tackle the rest in good time.
Sources please!
*cough* two core routers dual-stacked where I work, one scheduled for next wednesday, the rest to follow in the weeks following. Abilene supports IPv6 natively. CA*net supports IPv6 natively. SURFnet supports IPv6 natively. IPv6 traffic exchanged at LINX and AMSIX. NTT Europe launched commercial IPv6 service in Europe on 19th February.
Btw. Any chance you could ask your ISP for IPv6 connectivity? From your post it sounds like they could do with some customer demand. :)
Guys, there are a lot of misconceptions about IPv6. I appreciate this - it's not an intuitive subject, and it's possible to believe you know a lot more about it than you actually do. But, the details are there. Please do the reading and start asking your ISP for connectivity. No, your real ISP. There are people out there who want to deploy this, now, and we're waiting for customer demand. Go nuts!
Dave
I guess what you want to know is why your charge increases per bandwidth consumed rather than just a list of the various expenses ISPs incur (which other people have covered pretty well), which theoretically could be dealt with by a flat charge. Here's my understanding of that. Some of it's outside my area of direct expertise - I'll mark the point where we hit that.
As the bandwidth use in an ISP increases, the overall quality of service provided to its customers goes down (i.e. contention increases), until the ISP does the following:
You're probably already familiar with the difference between server hardware for 100 users and hardware for 10,000. Switches and routers tend to be a step upgrade; they work fine for three years then BANG you need to spend forty thousand euro, and that'll do you for another three years, or whatever.
Telco bandwidth costs money, and upstream ISP service over that bandwidth costs more. The increase in that is usually sublinear - 4Mbps costs a little less than 2*2Mbps, 8Mbps costs a little less than twice that. The reasons for those costs are where I start to leave the stuff I do for a living, but my understanding is this.
For internet service (this is different and separate from just getting a leased line!), the same principles as above apply, just on a bigger scale. The larger bandwidth user takes a larger chunk of the provider's resources, therefore they'll (within certain parameters) get charged commensureately more.
For the cost of the leased line itself:
That, of course, is without all the associated costs of running a business with more than two people in it, which are (to put it politely) non-trivial.
Dave
I hear you, and I definitely appreciate what you're trying to achieve. However, before you launch wholesale into such a world, I would ask you to consider this.
Believe it or not, the object of ICANN was to try to create a body that could succeed IANA and continue to allow us to make the decisions that needed to be made through consensus - the way we'd been doing it all along. The "rough consensus and running code" attitude of the IETF and other groups is what has turned out the useful stuff on the internet today - little things like TCP, SMTP, DNS - stuff like that.
If you "fork" ICANN, as it were, this is means a couple of things. One is that it's tantamount to an admission that consensus based decisions can't be made at this scale. Whether true or not, this would be a great pity IMO, and I'd like to see every avenue exhausted before we abandon such a great system for something less effective (like, say, democracy - something which is damn good, but despite best efforts seems to leave some people feeling a bit left out).
Also, when people are forced to make an exclusive choice, there is no guarantee that the "better" choice will win (FSVO "better" - cf. Betamax, Apple, etc etc). Further, if such a choice is forced, you may assume that the number of competitors will not remain at 2, and that some of the choices will be particularly powerful bodies that might not have the best interests of the network at heart.
If DNS names were no longer universal, do you assume that all browsers would continue to use DNS for lookup? What if they instead implement their own keyword search as a preference (perhaps giving free 1-year keyword licenses to all domain holders as of $DATE) so that "our customers get a consistent experience"? Might they succeed? If they did, would that be a positive thing?
Working within the system is often boring and frustrating. However when you are railing against perceived corporate takeover, remember how our actions, regardless of anyone's intentions, might give a company the opportunity to exercise their own "corporate takeover" at another level. It is absolutely within your rights and within your means to propose an alternative root. However, there is much to be lost by such a move, and there is much to be gained by, at least, trying to follow the backwards-compatible path until no other option remains.
Almost, not quite.
ICANN stands for "Internet Corporation for Assigned Names and Numbers". It is a non-profit set up a few years back to take over the duties of the Internet Assigned Numbers Authority.
One of these is the clerical duty of assigning /8 blocks of global IPv4 address space and /16 blocks of IPv6 address space to each Regional Internet Registry as needed. The users of the address space decide policy, and it's this policy that the RIRs implement.
Another duty ICANN took over is maintenance of the DNS root (which has been the controversial part), and a third duty is maintenance of the list of protocol numbers (imagine a link to your /etc/services just here - something's stopping me posting triple-slash).
But if you look at the IP address and nothing else, you can't uniquely identify the data coming back in order to cache it. Even if the packet is sent to the IP address you specified, the proxy must identify the HTTP query in order to store or pull the appropriate document from the cache. After all, a single IP address can serve multiple pages, never mind multiple virtual servers :-)
I guess you could rewrite the cache to store pages based on a [http request,ip address] pair, but that's going to cause, at best, a performance hit when dealing with any large multiple-IP site (the very kind of sites we want to cache; don't even start about Dynamic DNS), and is a substantial change to the behaviour of a HTTP proxy.
That's a lot of effort to put in in order to get a performance hit. I submit that the correct way to solve this problem is for the industry to agree on a common DNS root.
Dave
I see what you mean. You are sending traffic to a particular address based on your own DNS resolution, and if the traffic is proxied, you want it to be sent to your chosen destination, not that of the proxy.
In my opinion, the ISP is exhibiting correct behaviour.
Picture this: the object of the exercise with the transparent proxy is to cache pages and increase speed for the customer, right? I think it's already been agreed earlier in the thread that this is not entirely evil.
Let's say the proxy honours the destination IP address that you chose (I'm not sure how this would work in practice, but I'll go with it for now). It returns the web page from the server that your DNS picked, and caches it for the next guy.
Another customer requests a page with the same name. What if they're using a DNS root where the answer conflicts with yours? The customer gets the "wrong" web page. Because cached objects eventually expire, this means that the customer might get a completely different site dependent only on the time and date they happened request it.
The ISP doesn't use the same DNS root you do, so they can't begin to troubleshoot the problem.
I concede that the popular "alternate" DNS roots have few enough conflicts with the IANA-assigned roots at the minute, but even that is an irrelevancy - any solution that allows a customer to choose destination IP address on behalf of other customers opens up the ISP to a denial of service attack by a user less trustworthy than you or I. One could set up an arbitrary "root" server that resolves www.yahoo.com to my own site. Or google. Or some site that accepts credit card orders.
I can't see any scalable way out of this without the ISP picking one root, and sticking with it. If that is so, then I think this is a fundamental problem with split roots and, if you really want to use them, be fully aware of what you're getting yourself into. Turning off the transparent proxy will help this time, but you won't be able to rely on being able to talk to any server on the internet that doesn't use the same root as yours, even the servers you don't (usually) need to know exist.
Regards,
Dave
Same here, but I'm just on cover from home, and I volunteered for it.
Christmas is always very quiet, except the last couple of years where we had some pretty ugly weather and it knocked out power to a few places, but that's about it. My boss is fond of quoting that 80pc of network outages are caused by network engineers doing things. At Christmas, when no one's doing anything, everything's stable!
So I spend Christmas with my family, logging on occasionally, unlikely to get called in. And I get to take off out of the country for New Year while someone else takes the reins.
Not a peep so far, and I fly to Scotland on the 27th...
Dave
Without debating the whys and wheres of the rest of your post, let me take issue with this statement:
See, you've just fallen into the exponential trap. Take a look at this:
If these three statements are true - and I think they are easily verifiable - then...
Dave
BGP multihoming with provider independent address space is not the only way to take advantage of the resilience of IP. For one example in one situation, a customer can multihome (with physically diverse leased lines of course, right?) to two different PoPs of the same ISP, and route their PA space appropriately.
The advantage of this is that it doesn't require every core internet router to be aware of the multiple paths to your network; I have multiple paths to your ISP already, and they handle the resilience from there. This speeds convergence time for you (you don't want to wait for routers in US, Europe and Australia to all catch up with your flapping lines, do you?) and reduces the cost to me of maintaining a full routing table.
Address space is allocated based on how many addresses you need. Routability of small allocations isn't some grand conspiracy; it's a decision resting with each network based on just how costly it is to maintain a copy of the global routing table.
And while increasing the available address space is definitely a good thing, extra address space, as you say, won't solve that particular problem. However if the rate of growth of BGP multihomed networks is greater than Moore's law, neither will simply slapping extra RAM and CPU into backbone routers. Eventually the routing table will outstrip affordable router capacity and you will reach the same problem from the other direction.
IPv6 has some neat tricks that might actually reduce the dependence on BGP multihoming. In the meantime, consider the hassle of BGP multihoming for you, and see if there isn't actually another solution that fulfils your requirements better - there might not be, but you might be surprised.
Dave
[My opinions, not necessarily those of my employer]
Conceded. I went too far with that comment; thank you for the measured response. There's a lot of FUD about, I really shouldn't be adding to it.
Best,
Dave
--
Hi Chris,
Damn good response. There is a lot to think about in there. To respond individually will take time (I'd be glad to do so in email if you wish) and I think this story will have dropped off the front page by the time I'm done, so with your permission I'm going to concentrate on this:
I think this is at the centre of our differing opinions. Yes, I think the internet needs to evolve. No, I don't think you're doing so in the right way.
I like how the internet has evolved over time. I think it's fascinating to see a system built on real consensus come so far and overcome so many obstacles. I think it's amazing; there are lessons to be learned here in how we live the rest of our lives.
I don't think alternate roots are a part of this process - not yet, at any rate. DNS is a rigid hierarchy, and as a result, it's brittle. Conflicts must inevitably arise as we are beginning to see with the alternate .BIZ domains. I think this undermines the usefulness of DNS, and since we have never had to live with an inconsistent DNS before, I don't think the potential consequences are clearly understood.
I can't buy your assertion that DNS can never be replaced with proprietary solutions. These guys are masters of embrace+extend. It wouldn't happen overnight, but the prize of dominance is high - you become the de facto DNS replacement.
If this were any other protocol, big deal. But DNS is fundamental to the internet. When someone reports a network problem, it is the one thing I always check first, because it's the one ubiquitous protocol. I believe that:
I've been told "don't hinder progress" a lot. I've seen it used to justify everything from HTML news posts to .DOC as an email standard. That alternate roots exist is not just an indication that there is something wrong with the current system; I think it's a tragedy. But of all the alternate people who could hold the root - and in a world of 90pc Windows desktops, I do believe there'll eventually be only one root that matters - I have more faith in ICANN and its structures to ensure the continued life of a consensus-built net than I do anyone else.
There's been a lot of frustration at ICANN I think because of the appointed directors. That is changing. Much of the board is different, and what's left are also changing. The At Large directors are taking their seats, and more will be elected (it won't be limited to five as previous slashdot stories may have had you believe). There are a lot of good people on that board now, and not just on the At Large side.
And if we shouldn't give those guys a chance at making it work, who the hell else should we trust?
Your reasoning is excellent, Chris, and I wish I could be as optimistic as you. But I fear that in the root DNS we have encountered one of the potential vulnerable spots of the whole internet, and right now I do not wish to take the risk of breaking it.
Dave
--
You're right, there's a fair amount of power wrapped up in the various slashdot readers. And this slashdot reader sure as hell won't be joining you in your protest.
I know it's trendy to slag off ICANN. I know everyone has their problems with it. I know everyone feels like the only thing they can do against this new authority is to shout about it, or to "rebel". And in that context, splitting the root seems like a fantastic idea.
Don't do it, guys.
Internet "precendent" says that we've tried to work out problems through consensus building. Seriously! We get together in groups like RIPE and NANOG, present our ideas, and try to build consensus. We can fork, yeah, but we fork as little as possible, because when we fork, we split the user base and we are all weaker because of it.
But that's not the worst of it in this case.
Ever since domain space became valuable, there are so many special interests circling it that it's not funny anymore. It's pretty ugly, actually. Consensus building has been pretty impossible because people with dollar signs flashing in their eyes shout louder, and the people who are just plain kooks shout the loudest. That's hurt a lot of the development of DNS in the last few years. The one weapon we've always had against this is caution, and a recognised authority.
All those special interests are sitting, eagerly awaiting the day when a significant majority of admins reject ICANN and switch to another root. When that happens, they'll turn on each other, and that's when it gets ugly.
You think you have user problems because people think that "The Internet" is the thing behind the button on their Windows desktop? That's nothing compared to what we (all of us) will have to deal with if we split the root.
I'm speculating now, but here's my guess. See what you think:
Don't be fooled into thinking that everyone pushing for alternate DNS has the good of the internet at heart. Some of them mean well, I'm sure. Some of them are sound guys. I'm equally sure that some of them are out to grab a piece of the gold mine that is DNS, and are willing to damage it in the process. Believe it or not, ICANN is the one thing standing between us and a corporate takeover of the internet.
Yeah, I just wrote that with a straight face. I mean it.
To drag this back on topic? We're seeing the beginning of this now. Everyone's been bitching at ICANN to hurry up and introduce some new TLDs already (watch for buzzwords such as "artificial scarcity" in other slashdot posts near you!) What happened? Someone tried to preempt them and lured a some-thousand userbase to give themselves some credence. What do ICANN do here? Reject potentially better-prepared proposals for favour of this one? I don't think that's fair.
Guys, you really should know better than to measure something's worth through the count of its [slashdot|newspaper] headlines. Jon Katz had this one nailed down years ago. A lot of the criticism against ICANN is genuine; a lot of it's crud; and a lot of it ignores the best interests of the internet.
Think for yourselves. Don't be afraid not to fork.
Dave
Posted with mozilla 20000112721--
[Disclaimer: I don't work for/on Netscape or Mozilla, I just reported a few bugs]
You got examples? Fantastic! That's useful info for the developers. So why are you crippling yourself by using PR2?
PR2 is cool, but it's a packaged beta, and it's already old code.
You can prepare useful reports on reproducible bugs. Get the latest binary, check if the problem still exists, then report it straight to the developers.
Seriously. You don't need to put Some Faceless Corp between you and the coders anymore. You've got a direct line!
Have fun,
Dave
--
Russ Cooper just posted a more educated summary of the problem to NTBUGTRAQ. It's in the archives at this location.
It's NOT as bad as first reported. Russ says that his comment that it affects "almost every web hosting provider" was based on the info that it was some sort of Front Page issue. It's not that simple, and it seems that it's only exploitable by users who have already been granted web authoring permissions on the box.
Have fun,
Dave
--
If you want to create a second way in, man, go ahead. Write a CGI script to exec sshd or something. But you don't need the maintainers of Apache to do that for you; you don't need that capability hidden from you; and you sure as hell don't need that capability being discovered in someone else's system on the other side of the globe and then exploited in yours while you are taking your first holiday in 2 years...
Backdoors, done properly, have their place. That place is not implemented unknowingly in thousands and thousands of installations worldwide where such a backdoor would be wholly unsuitable anyway.
Make no mistake. Whatever this is, it's not a feature.
Dave
(Still using mozilla 2000041316)
--
You send a tech to let you back in through a well known and documented procedure that allows full access from the console, a feature you knew about and chose not to disable.
The fact that backdoors can be useful does not excuse one being placed silently in a piece of software that is then marketed as secure. You may approve of having a remote back door; you may believe that the risk is sufficiently small to justify the potential cost savings. That's great. But that is a decision for each customer to make, and not every customer will agree.
Separately, it's my opinion that a common remote backdoor, no matter how well hidden, will turn round and bite you on the arse eventually. This software is too well deployed; too many people are auditing it and probing it. If an engineer puts 100 hours of work into hiding it, it only takes 100 people 1 hour of searching to equal that effort. How before someone makes that discovery? And how long after that before it is widely reported anywhere other than IRC?
Dave
(posted with Mozilla 2000041316)
--
Jon,
I'd really appreciate if you could ask the WAVE people how they plan to deal with its potential as a tool for bullying.
WAVE strikes me as an easy, anonymous and rewarding ($$$, t-shirts) way to cause instant grief to a fellow pupil. Kids who are willing to break a kid's bicycle lights, ostracise her in the yard, or embarrass them in the classroom on a permanent basis, will have no qualms about abusing this company's tool to get anyone quiet or different into trouble.
Now what I suspect is that, further to the above, the company's mechanisms will not be sufficient to catch such abuse.
Remember Independence Day? Remember the drunkard pilot who dusted the wrong field? Remember the TV interview with his "friends" who said, "Nice guy. Harmless guy. But the aliens abused him. Sexually."
Picture this now: an anonymous tip is received, "this guy's trouble". The class is identified. Now I don't know what WAVE's procedures are, but I reckon they're not going to just use a single anonymous tip-off before hauling in the kid, right? Surely they'll interview other kids first to make sure it's not just a grudge thing?
In a class of thirty, you will get twenty-four people who say "Dunno. He's quiet all the time. Noone seems to like him." and five who, for the laugh, will make up half-truths for the interviewer to make the kid seem as disturbed as possible.
Interviewer files his report, which is processed and added to the statistics database that will be presented to customers at the end of the year saying "we dealt with 100,000 potentially distressed students this year".
It's easy to see the individual elements of WAVE as pretty harmless in themselves. But taken together:
Dave
--
The other comments about rsync et. al. are spot on for replicating (rsync is great), but they don't address the problem of authority; if a file exists on a particular server, is it new (so replicate) or old (so delete)?
I think you need an upload procedure to get around that. Try this:
There are a couple of issues with this, but you can get around them with a little added complexity in your uploading-to-master algorithm. If the master server goes down then it's true, you can't update; but the master doesn't need to be static, it just needs to be consistent. If uploads are that critical, you can use another protocol - say DNS? - to designate an arbitrary server as master.
Dave
--
Inktomi, last I looked, don't run a search engine site; they develop the tech and license it to others who get involved in the messy business of making a popular search engine site.
IIRC, their highest profile customers are Hotbot, who used Inktomi from the start, and Yahoo!, who switched from Alta Vista to Inktomi. Inktomi is a more neutral backend for Yahoo!, who are competing in the same market as Alta Vista.
Dave
--
Woah. Woah there. Slow down just a second.
Right. Burn 'em at the stake? Let's see why again?
They didn't say they did. They said they will.
Right, I just don't get this. Do you know how long a scan takes? I'm not talking a script kiddie's nmap for open ports. I mean systematically probing an entire network for a stated behaviour with a sufficient timeout that you won't miss really slow servers (like, oh, say, ones that are already pumping piles of spam). They announced they'd start this as of today. Clue: it's not done yet.
And what do ports 8000 and 8080 have to do with this anyway? Are you talking about web proxies? They're a problem, sure, but tell me again how scanning for web proxies will get @Home out of the UDP? Can you even tell if @Home is scanning you on the NNTP port?
Heh. Gotta love the way you admit breaking your own ISP's rules on a public forum. And there are ways to judge relative security of an ISP. "I've run lots of scans and not been busted yet" is not one of them.
Signal 11, and everyone else, stop jumping on people when they admit they have a problem. This is good. @Home are doing the right thing when they admit this. It is the vital first step without which no further action can be taken. I know it's tempting to scream and roar at someone because they're evil, or because they snubbed you in the past. But these same people that are evil or snubbed you are the ones that we most need to take this step.
Please. If you think you can challenge @Home's statement, forward your evidence to the UDP people so they can consider it properly (clue: slashdot is not the best place to do this). But every time I see someone taking that first step and being met with ill-informed cries to burn, let 'em burn, I have to ask myself if I can actually ask the next guy to take it in good faith. I'm rapidly coming to the conclusion that I can't.
Dave
--
I compiled it this morning. It rocks.
The announcement was a little quick off the mark - binaries are due to be posted within the next couple of hours - but Mozillazine (great site) has news of M12 binaries for Solaris and RPMs for Red Hat
The speed at which Mozilla has come along recently is something else. If this isn't alpha, then it is damn close. Download, enjoy, and report those bugs!
Dave
--
[Discl: I know nothing about BSD, and less than I ought to about Linux devel. Below is a misquote of what I heard on Thursday. Feel free to correct.]
He got called on that one. There were a fair number of BSD followers in the audience. (And someone selling BSD CDs at the start...)
His point was that BSD has one really nice feature that's gorgeous on the surface but has a huge hidden cost. One make can build the whole system.
This is really good - but it's brittle.
If you submit a patch to Linus, and it's rejected - it's a patch, it's not too painful to apply manually, and it's not too painful to keep up to date. This, and the general taboo against forking, help keeps Linux moving in one direction.
However, if you submit a change to one of the BSD development groups, and it is rejected, then because you have to fit it into this huge, single structure - it's actually easier to clone that structure and spin off in your own direction.
He was pressed further, and in the end, everyone was right - the BSD people made good points about BSD (the userland is the same), and Eric and others made good points about Linux (the kernel is the same).
But I don't take your point about FUD. He doesn't like the look of Win2K - fine. But that doesn't invalidate his arguments. He has sound philosophical reasons for his beliefs, the condition of W2K does not invalidate those reasons. Unless W2K works miracles, it's possible that it may bear them out.
Dave
--