Actually you are the one who is confused... about what my post meant. I'll be less subtle and try to get to the points for you, so you don't have to hurt your head to figure it out.
Sun does make a 64-bit CPU. My point is why should they abandon that? Why not leverage that to bring customers closer to their high end enterprise systems?
Sun doesn't have an interest in enabling the running of Microsoft Windows (at least not as I understand it). So what's the value of an x86-like architecture that Microsoft will be porting (or already has ported) Windows (at least server editions) to? I can seem making Solaris work on it as a way to enable bringing new customers into the fold. But I don't see why to deploy a hardware product line on that CPU.
Of course a $100 64-bit CPU would be nice. But I'm not silly enough to expect that for a while. But that's neither here nor there. Is the AMD design going to become the $100 64-bit CPU first? Sounds like Sun is just giving up on all their leverageability. Instead, they should be working on making a commodity grade (read: low end) version of the UltraSparc for entry level 1U rack servers and desktops. Then businesses can know that their applications will already work on Sun Enterprise hardware once those businesses are ready for that scale. What kind of high end machine will AMD Opteron machines lead Sun customers to?
My primary goal is getting off x86. Close behind that is getting to 64-bit. But if the only way to get off x86 (and I include x86-like 64-bit architectures) is to go 32-bit for now, that's fine. And no, I won't be giving you any grief about 64-bit, as there is where we are all going. But the best architecture will be one that allows userland processes to work in either 32-bit or 64-bit address modes under a common 64-bit kernel with prerrably a common 64-bit dynamic loader and shared library (but if these parts need to be different for 32-bit and 64-bit processes, then that's livable). IBM's PPC 970 is definitely on my radar right now! If someone were to develop a PPC 970 emulator that ran on other machines, with the quality level of Hercules (for the S/390), then a whole lot of people could be playing with building software, testing software, and even building systems, for that platform... to be ready when they can afford the real hardware.
I don't have an AT286. Hell, my old Pentium 75 hasn't seen power for 3 years now.
Anything that needs serious cycles goes on the S/390 or AS/400s.
Either the apps you've deployed on those machines are more I/O hungry than CPU hungry, or you've wasted dollars on mismatched architecture. S/390 and zSeries (no comment on AS/400 since I don't really know that one) are great machines if you need absolute up time and fantastic I/O throughput. But for CPU power, while those machine do have some, they are not giving you the bang for the buck you can get with a farm of P4s or AMDs. So maybe the reason you do have those machines is for something other than, or in addition to, CPU power needs. Does your S/390 serve web pages? Is it running a database? Does it have a PCICA?
I thought Sun already had a 64-bit CPU. And I heard that CPU won't run Windows. Since Sun wants businesses to buy Solaris instead of Windows, that would seem like the thing to do, since that would narrow down the competition to basically just Linux. Do they think Microsoft isn't going to sell Windows for these CPUs?
Personally I'd love to have a CPU architecture that fully departs from the x86 designs, whether it be 32 bit or 64 bit (or a hybrid). I'd just run Linux or BSD on it. Such CPUs exist now, but they simply are not at commodity pricing, yet. Of course companies like Sun and IBM would rather not have to deal with such pricing. So we're probably stuck with x86 CPUs for a few more years until the high end people shake out what CPU they will use, then all the clone makers will leech.
Sure, it is doable to have a single IP working HTTP requests by name and have each site or group of sites (same user) have a dedicated server. I don't know how easy it could be retrofitted into Apache, but certainly one way to do this is to have a front end like a proxy that checks the host of the request and routes the request accordingly. Maybe that could be routed to a different port number according to a configured map. But I would be more inclined to route the requests to a named pipe in the filesystem.
Even bind mounts are not secure. They can be remounted read/write, assuming they were read-only to begin with. One way to be sure that can't happen is to have the filesystem so mounted be a loopback to a file which resides on a filesystem which is mounted read/only. That underlying filesystem cannot be changed from inside the chroot (because there is no mount point therein to reference it), so even if the loopback mounted filesystem is made read/write, write attempts should ultimately fail (but even this could be exposed by a bug I don't know about, if one exists).
Modular programming (and dynamically loaded libraries are a form of modularity) just doesn't mix well with security.
There are certain things that have to work inside chroot for it to remain usable for the things it was originally designed for, which includes building new systems. Those things that are designed to fail (e.g. pass the test) in grsecurity's system, which fail the test (e.g. the code still works) on the others, are needed for many use that chroot is used for. For example you can't make a new system without being able to use mknod and use the device made in that run. And that's a capability which can be abused.
The problem is people are trying to take something that seems like it might have been intended for security (chroot), which never was, and trying to impose on it a more complete set of semantics that would force it to be usable for security, breaking the original purpose. Instead, what should be done is create an entirely new tool. FreeBSD has the jail feature which is a sort of "chroot on steroids". And Linux has "User Mode Linux" which allows running a whole kernel in user process space.
My point is, chroot was never intended to be secure. Shame on those who ever expected it to be so.
I've always set up Apache so CGI runs as the user who owns the site. The problem is, that requires retaining the permission to switch to that user somewhere, even if just within the "suexec" file (is suid root).
The problem with Apache is that it is so large, and so much code would run as root, that it is unsafe to allow that. So the usual course is to run Apache non-root, and let "suexec" do the permission switch. Supposedly it can verify if it is being run correctly from the Apache process (as opposed to from any other) by means of a passed random number it can read from a file only Apache could write. But I never have really verified how that works, and shame on me for not doing so.
At some point we just have to trust some code to do the right thing with the permissions granted to it. I for one can't grant that trust without being able to read and understand the code. And Apache is just too much for that.
Perhaps the whole model of a multi-user shared daemon is all wrong. Maybe users should have to each run their own instance of Apache on separate IP addresses (they have to if they want to run an HTTPS secured web site, anyway).
Maybe Moore can have the excuse of ignorance, but from this day on, no other spammer can claim this. If they want to spam while using their home as a business, they have to accept the risk of brown boxes coming to their home.
If someone does send them something that blows up, I would not blame Uy for that, since the information is actually public, anyway. Someone so intent on harming Moore as to send such a package could get the information anyway, such as by actually responding to spam and seeing where that leads. Such a person could do all that Uy did. If harm befalls Mr. Moore, it is Mr. Moore who is most to blame. Most people's home addresses are public info. Yes, a line was crossed, by that was done by Mr. Moore. Uy is just trying to push him back.
It might be a bad thing, depending on the end result. If the USSC ends up ruling that states can force ISPs, even in other states, to do the filtering, and not have to release the list, then everyone is screwed. We can hope for the best, but there is no assurance it will happen.
How the hell are ISPs supposed to be able to implement and deploy this blocking according to the official list if they are not given a copy of the list? And doesn't that law at least claim it applies to any ISP, even out of state, as long as it serves customers in Pennsylvania... at least for the Pennsylvania customers? I'd like to know if the list consists of IP addresses, domain names, or complete URLs (or some mix of these).
If the list has IP addresses only, then it would be theoretically possible to deploy this in a router access list. But many routers don't scale well with large lists because of sequential implementation. And what if the web site in question changes IP address periodically? Does the IP address list get updated equally as often?
If the list has domain names, perhaps those can be remapped to IP addresses regularly, and put in the access list.
In either case, using IP addresses has "collateral damage" effects on other web sites sharing the same server, and maybe even other services if not deployed to specific ports (e.g. other connections like SMTP won't work). I'm sure that Mike Fisher, who is so full of himself that he tries to make people think he is the only attorney general around by registering attorneygeneral.com and attorneygeneral.gov, won't care (using the same theory spam fighters use that if the ISP hosts bad customers, then everyone should suffer until the ISP stops hosting them or goes out of business).
Or perhaps the list consists of URLs, including path names to specific site areas or user pages. The problem is most routers can't deal with that at all. You need a web proxy. That means ISPs now have to pay out more money to run web proxies, with all their associated problems, such as DNS lookup failures for users accessing web sites in different DNS realms (e.g. DNS name spaces NOT rooted at the normal ICANN root servers) or with add-on TLDs (e.g. pseudo-realms that take normal TLDs and combine with special TLDs like... uh... the ".xxx" and ".sex" TLDs). And what about accessing HTTPS sites via the proxy? The certificates won't match up unless the browser is configured to "trust" the proxy (e.g. accept the proxy's certificate for that half the end-to-end path, or just connect to the proxy unencrypted and ask for an HTTPS URL). If the ISPs don't filter on HTTPS, then the porn sites that are intended to be blocked can just make HTTPS work. OTOH, if the ISPs force proxying HTTPS, that becomes a major privacy violation.
So one way or the other, porn sites can evade the blocking. If blocked by IP address, they just move around... maybe as often as every 5 minutes with very dynamic DNS or other very highly distributed methods. And if blocked by URL, they can use HTTPS to bypass proxies or force the ISPs to invade secure web privacy. And if blocked by domain name in the DNS server (using local authoritative zones) users can get around that by not using the ISP DNS servers, running their own DNS servers, or the porn site can register more domain names (they're cheap for porn operators).
And with tens of thousands of open proxies around the world (check today's load of spam for more addresses), there's going to be plenty of ways for perverts to get their fix once they learn these methods. Is the PA AG going to track all the open proxies out there, too?
But in either of these cases, there isn't much the ISP can do without the list. And I didn't see anything in the text of the law that says the list has to be held in strict confidence by the ISP (as if that would apply to an out of state ISP anyway).
Yes I have dealt with NAT. And no, it isn't easy. And yes, having IPv6 would make things easier.
But put blame where blame is due, on the IPv6 development and deployment. There are two fundamental problems. One is the routing architecture development didn't keep up, and two, there is no incentive being created to migrate to IPv6. Don't expect most ISPs to care to do anything within IPv6 until there is a real incentive. Of course the biggest incentive would be a return on investment. Other incentives would be to make it free. For example, give away free, permanent, and portable IPv6 space to just enough early adopters (who will be required to deploy it within a fixed time frame to keep it, such as 3 months, and tunneling OK until their upstream deploys direct IPv6 routing) to create enough critical mass to bring everyone else on board. And don't whine about the routing not being scalable enough to handle this because I am not proposing that everyone get this free, permanent, and portable space... just the early adopters... just enough to create the critical mass. Then at some point no more freebies will be available (it then goes back to justfied need).
Why should I bother to deploy IPv6 when I can't get portable space? That's the biggest thing I need right now. And it's NOT an issue of renumbering machines when I change upstream providers. Instead, it's an issue of dealing with all the references to fixed address references in other deployed systems, documentation, distributed material, etc, where the benefit of LAN prefixing isn't there. I do wish domain names covered everything, but unfortunately that simply isn't the case (try putting domain names in place of IP addresses in your/etc/resolv.conf file, for example, especially on a system burned into a CD-ROM).
It's the IPv6 promoters that need to get their heads out of the sand.
Re:Linux use hurtsd us economy
on
BSA IDC FUD
·
· Score: 2, Insightful
So if I lived in some poor third world country, and happened to have just enough money to buy some legal, non-pirated, commercial software, imported from some big industrialized nation with a huge IT sector, then... I couldn't spend that money on something else like feeding my children. Do these idiots at BSA think that when people don't spend money on something like software, that they end up just burning it as cooking fuel?
The reality is the cause and effect is the other way around. Piracy always exists, and it mostly exists among those who don't have much to lose if they get caught, or are sure they won't get caught, or just don't have the money to buy it in the first place. It's the existance of a strong IT sector that generates market for software, which in turn generates revenues for those who sell it (domestically or internationally).
The message BSA should be sending out is:
You need to build a strong IT sector so that we can have a market for our lousy buggy software. But don't get into the business of making software that competes with us and for heaven's sake don't use Linux.
There's plenty of address space remaining in IPv4 right now. Sure, it will eventually run out if nothing replaces it. That was originally projected to happen even before 2000. Now it looks like it won't be until after 2012 or 2015 or so. In the mean time, no incentive to switch to IPv6. But there is time to go back to the drawing table and redo the architecture right this time and include a scalable routing system. And yes, I have already thought out a way to do it (but I'm not in the elite circle of RFC writers, so they will just have to figure it out on their own, if they can).
Yes, I know it is a routing issue. In the panic (FUD) of imminent IPv4 exhaustion, the developers completely ignored the needed routing scaling issues. They were so worried about getting enough addresses, they didn't bother to make sure they would be fully usable. Likely the problem was that they were in such a hurry, they just didn't have time to do the research to make a scalable routing architecture to go along with it. That's such a shame, too.
BTW, all your description of what would be wrong with routing with millions of portable networks in IPv6 is based on the existing antiquated routing architecture the internet is currently running on (BGP4), and it's 128-bit version for IPv6 which doesn't really add any scalability (just adds longer prefixes and a few new functions).
The problem is, I already have hundreds of clients running systems with/etc/resolv.conf pointing to my DNS servers. I've already had to update those once, and it was a royal pain. Fortunately I had a 4 month overlap window where I was running on both the old and new address spaces at the same time.
Portability of IP address space is not about changing your IP address on the computers on that network; it's about changing the references to those addresses that would be present on machines outside of the network. And those have to be a full reference, including the prefix. DNS servers come to mind as one example where the address is mandatory. The actual renumbering of the servers on the network is trivial. I've done it so many times that's not a problem. The problem is in changing the references.
No, IPv4 won't last forever. But things like NAT and private addresses have definitely extended its life. Maybe even long enough to get a decent new IP architecture with scalable routing.
But that address space won't work when I switch provider. I get my IPv4 address spaces from my provider now, and they have the same problem, and IPv6 isn't solving it. I can't get a big portable allocation of IPv4 because IPv4 would run out if they did that. IPv6 won't, but they still won't give out portable address space because they forgot to deal with the routing issue. So now they've got this "spruce goose" of a new IP architecture which is probably going to have to be replaced anyway to do a universal portable routing architecture correctly. Not only do I not see any benefit to deploying IPv6, I even see costs which will likely be incurred over the next decade as they discover that all this was a waste of time, hurried along because of a sudden panic over fears of IPv4 space exhaustion (fears that were initially valid, but were also well dealt with).
Part of the problem goes all the way back to the flaws in the original requirements for IPv6. The flaw is that IPv6 was intended only to add address space, and not deal with the more serious scaling issue of routing. Unfortunately, routing is a complex problem which just doesn't readily fit into the kinds of address space technology both IPv4 and IPv6 are based on. The problem with routing the way it is done now is that every autonomous system has to be represented with the prefix of their address space in the routing table of every backbone router. So now we take routers which are expected to handle millions of packets a second and require them to store millions of route entries (this would be the case if everyone gets their own portable address space). Even though IPv6 has enough address space to give everyone in the world billions of addresses, they have no intent to ever do this on a permanent basis because they didn't think about the routing scaling issues before they jumped the gun and made yet another flat address model.
Do you believe IPv6 will be widespread enough by the time they start closing the temporary solutions?
I seriously doubt it. It's a chickend and egg problem. Most companies are avoiding upgrades, patches, and service packs on just about everything. And you expect them to suddenly embrace IPv6 for no reason (what can they do that IPv4 can't do?)? Will there be anyone who will be running reachable only via IPv6? Well, a few geek sites will be there, but nothing for real world business and the average consumer. So no need for IPv6 and no desire for IPv6-only. It's DOA.
So IPv6 will cost $. So what's the incentive to deploy IPv6 if it costs $ and doesn't return any? Welcome to the capitalist world where everyone expects a return on investment. The only incentive to do IPv6 is the "geek factor" and 6bone is about to eliminate that.
So where the hell is www.slashdot.org? nslookup -q=aaaa www.slashdot.org Can't find www.slashdot.org: Non-existent host/domain
Why do they need to be on IPv6? Hell, even Slashdot won't qualify for permanent IPv6 address space. One reason is that everyone has IPv4. When there are finally some people who are on IPv6-only, then it will be time to get Slashdot and other places on IPv6 (in addition to staying on IPv4).
It's not about whether IPv6 is going away or not. Obviously it's here to stay. But unless the IPv6 folks get their heads out of the sand, it will stay... dormant. Give me a reason to be an early (e.g. before there are IPv6-only users) deployer of IPv6. And no, I don't mean on some limited tunnel network; I mean real natively routed IPv6 with my very own IPv6 address space (there's plenty of it to go around now in case you haven't noticed, although it sure seems a lot of people haven't).
Still, SUN machines of the desktop category are better hardware than commodity PCs. Maybe there are some exceptions, or at least some machines which come very close. But they will probably be as expensive, if not more so. The point is there is justification to buy SUN Sparc hardware for things on the "low end" such as desktops. Much of that market needs Solaris for many reasons. But not all of it. Linux is justified in many cases. Of those, some may just run Solaris anyway. Others may just run Intelish PCs anyway. SUN loses the business of the latter group to some extent, and others run Linux anyway, but not at the full capacity because of poor SUN support (e.g. they can't use StarOffice).
Too bad you can't comment on Linux on Sparc. That's my whole issue. And that's why I no longer recommend SUN machines to anyone except the high end enterprise class servers (and even then not in all cases, as some are better off with IBM S/390, a high end 5+ 9's machine for which Linux support does exist, but for which a desktop market is entirely absent). What I want is a highly reliable 64-bit desktop Linux that's not based on an Intel x86. What do you suggest to get that?
Given that IPv4 space is no longer at risk of being exhausted, there is virtually no real incentive to switching to IPv6. The only one that exists right now is the "geek factor", a measure of "coolness" recognized only by other geeks (and then, most of those are now considering it to be boring).
Had the IPv6 proponents really wanted to get more people to switch to IPv6, they would have wised up and offered something substantial. Free IPv6 addresses in the 6bone that were never intended to be permanent simply brought out just a small limited response. But if they had offered real permanent addresses, maybe a lot more people would have responded.
Although IPv4 space is no longer at risk of running out, it does have limitations that prevent any substantial portable address space from being allocated to all who want it. IPv6 has that space. There is no excuse for not doing so. But the IPv6 people are trying to make using IPv6 hard by their absurd policies. They have no one to blame but themselves why so many are not migrating to IPv6.
I do have IPv4 space. For places potentially running only IPv6, there will be the IPv4 equivalency range of IPv6 which I can use. But I won't have any reason to deploy that until after there are a substantial number of IPv6-only locations. Of course, no one will want to have only IPv6 until enough reachability exists in IPv6. Chicken. Egg.
Slashdot Mirror
Actually you are the one who is confused ... about what my post meant. I'll be less subtle and try to get to the points for you, so you don't have to hurt your head to figure it out.
Sun does make a 64-bit CPU. My point is why should they abandon that? Why not leverage that to bring customers closer to their high end enterprise systems?
Sun doesn't have an interest in enabling the running of Microsoft Windows (at least not as I understand it). So what's the value of an x86-like architecture that Microsoft will be porting (or already has ported) Windows (at least server editions) to? I can seem making Solaris work on it as a way to enable bringing new customers into the fold. But I don't see why to deploy a hardware product line on that CPU.
Of course a $100 64-bit CPU would be nice. But I'm not silly enough to expect that for a while. But that's neither here nor there. Is the AMD design going to become the $100 64-bit CPU first? Sounds like Sun is just giving up on all their leverageability. Instead, they should be working on making a commodity grade (read: low end) version of the UltraSparc for entry level 1U rack servers and desktops. Then businesses can know that their applications will already work on Sun Enterprise hardware once those businesses are ready for that scale. What kind of high end machine will AMD Opteron machines lead Sun customers to?
My primary goal is getting off x86. Close behind that is getting to 64-bit. But if the only way to get off x86 (and I include x86-like 64-bit architectures) is to go 32-bit for now, that's fine. And no, I won't be giving you any grief about 64-bit, as there is where we are all going. But the best architecture will be one that allows userland processes to work in either 32-bit or 64-bit address modes under a common 64-bit kernel with prerrably a common 64-bit dynamic loader and shared library (but if these parts need to be different for 32-bit and 64-bit processes, then that's livable). IBM's PPC 970 is definitely on my radar right now! If someone were to develop a PPC 970 emulator that ran on other machines, with the quality level of Hercules (for the S/390), then a whole lot of people could be playing with building software, testing software, and even building systems, for that platform ... to be ready when they can afford the real hardware.
I don't have an AT286. Hell, my old Pentium 75 hasn't seen power for 3 years now.
Either the apps you've deployed on those machines are more I/O hungry than CPU hungry, or you've wasted dollars on mismatched architecture. S/390 and zSeries (no comment on AS/400 since I don't really know that one) are great machines if you need absolute up time and fantastic I/O throughput. But for CPU power, while those machine do have some, they are not giving you the bang for the buck you can get with a farm of P4s or AMDs. So maybe the reason you do have those machines is for something other than, or in addition to, CPU power needs. Does your S/390 serve web pages? Is it running a database? Does it have a PCICA?
I thought Sun already had a 64-bit CPU. And I heard that CPU won't run Windows. Since Sun wants businesses to buy Solaris instead of Windows, that would seem like the thing to do, since that would narrow down the competition to basically just Linux. Do they think Microsoft isn't going to sell Windows for these CPUs?
Personally I'd love to have a CPU architecture that fully departs from the x86 designs, whether it be 32 bit or 64 bit (or a hybrid). I'd just run Linux or BSD on it. Such CPUs exist now, but they simply are not at commodity pricing, yet. Of course companies like Sun and IBM would rather not have to deal with such pricing. So we're probably stuck with x86 CPUs for a few more years until the high end people shake out what CPU they will use, then all the clone makers will leech.
Sure, it is doable to have a single IP working HTTP requests by name and have each site or group of sites (same user) have a dedicated server. I don't know how easy it could be retrofitted into Apache, but certainly one way to do this is to have a front end like a proxy that checks the host of the request and routes the request accordingly. Maybe that could be routed to a different port number according to a configured map. But I would be more inclined to route the requests to a named pipe in the filesystem.
Even bind mounts are not secure. They can be remounted read/write, assuming they were read-only to begin with. One way to be sure that can't happen is to have the filesystem so mounted be a loopback to a file which resides on a filesystem which is mounted read/only. That underlying filesystem cannot be changed from inside the chroot (because there is no mount point therein to reference it), so even if the loopback mounted filesystem is made read/write, write attempts should ultimately fail (but even this could be exposed by a bug I don't know about, if one exists).
Modular programming (and dynamically loaded libraries are a form of modularity) just doesn't mix well with security.
There are certain things that have to work inside chroot for it to remain usable for the things it was originally designed for, which includes building new systems. Those things that are designed to fail (e.g. pass the test) in grsecurity's system, which fail the test (e.g. the code still works) on the others, are needed for many use that chroot is used for. For example you can't make a new system without being able to use mknod and use the device made in that run. And that's a capability which can be abused.
The problem is people are trying to take something that seems like it might have been intended for security (chroot), which never was, and trying to impose on it a more complete set of semantics that would force it to be usable for security, breaking the original purpose. Instead, what should be done is create an entirely new tool. FreeBSD has the jail feature which is a sort of "chroot on steroids". And Linux has "User Mode Linux" which allows running a whole kernel in user process space.
My point is, chroot was never intended to be secure. Shame on those who ever expected it to be so.
I've always set up Apache so CGI runs as the user who owns the site. The problem is, that requires retaining the permission to switch to that user somewhere, even if just within the "suexec" file (is suid root).
The problem with Apache is that it is so large, and so much code would run as root, that it is unsafe to allow that. So the usual course is to run Apache non-root, and let "suexec" do the permission switch. Supposedly it can verify if it is being run correctly from the Apache process (as opposed to from any other) by means of a passed random number it can read from a file only Apache could write. But I never have really verified how that works, and shame on me for not doing so.
At some point we just have to trust some code to do the right thing with the permissions granted to it. I for one can't grant that trust without being able to read and understand the code. And Apache is just too much for that.
Perhaps the whole model of a multi-user shared daemon is all wrong. Maybe users should have to each run their own instance of Apache on separate IP addresses (they have to if they want to run an HTTPS secured web site, anyway).
Maybe Moore can have the excuse of ignorance, but from this day on, no other spammer can claim this. If they want to spam while using their home as a business, they have to accept the risk of brown boxes coming to their home.
If someone does send them something that blows up, I would not blame Uy for that, since the information is actually public, anyway. Someone so intent on harming Moore as to send such a package could get the information anyway, such as by actually responding to spam and seeing where that leads. Such a person could do all that Uy did. If harm befalls Mr. Moore, it is Mr. Moore who is most to blame. Most people's home addresses are public info. Yes, a line was crossed, by that was done by Mr. Moore. Uy is just trying to push him back.
It might be a bad thing, depending on the end result. If the USSC ends up ruling that states can force ISPs, even in other states, to do the filtering, and not have to release the list, then everyone is screwed. We can hope for the best, but there is no assurance it will happen.
How the hell are ISPs supposed to be able to implement and deploy this blocking according to the official list if they are not given a copy of the list? And doesn't that law at least claim it applies to any ISP, even out of state, as long as it serves customers in Pennsylvania ... at least for the Pennsylvania customers? I'd like to know if the list consists of IP addresses, domain names, or complete URLs (or some mix of these).
If the list has IP addresses only, then it would be theoretically possible to deploy this in a router access list. But many routers don't scale well with large lists because of sequential implementation. And what if the web site in question changes IP address periodically? Does the IP address list get updated equally as often?
If the list has domain names, perhaps those can be remapped to IP addresses regularly, and put in the access list.
In either case, using IP addresses has "collateral damage" effects on other web sites sharing the same server, and maybe even other services if not deployed to specific ports (e.g. other connections like SMTP won't work). I'm sure that Mike Fisher, who is so full of himself that he tries to make people think he is the only attorney general around by registering attorneygeneral.com and attorneygeneral.gov, won't care (using the same theory spam fighters use that if the ISP hosts bad customers, then everyone should suffer until the ISP stops hosting them or goes out of business).
Or perhaps the list consists of URLs, including path names to specific site areas or user pages. The problem is most routers can't deal with that at all. You need a web proxy. That means ISPs now have to pay out more money to run web proxies, with all their associated problems, such as DNS lookup failures for users accessing web sites in different DNS realms (e.g. DNS name spaces NOT rooted at the normal ICANN root servers) or with add-on TLDs (e.g. pseudo-realms that take normal TLDs and combine with special TLDs like ... uh ... the ".xxx" and ".sex" TLDs). And what about accessing HTTPS sites via the proxy? The certificates won't match up unless the browser is configured to "trust" the proxy (e.g. accept the proxy's certificate for that half the end-to-end path, or just connect to the proxy unencrypted and ask for an HTTPS URL). If the ISPs don't filter on HTTPS, then the porn sites that are intended to be blocked can just make HTTPS work. OTOH, if the ISPs force proxying HTTPS, that becomes a major privacy violation.
So one way or the other, porn sites can evade the blocking. If blocked by IP address, they just move around ... maybe as often as every 5 minutes with very dynamic DNS or other very highly distributed methods. And if blocked by URL, they can use HTTPS to bypass proxies or force the ISPs to invade secure web privacy. And if blocked by domain name in the DNS server (using local authoritative zones) users can get around that by not using the ISP DNS servers, running their own DNS servers, or the porn site can register more domain names (they're cheap for porn operators).
And with tens of thousands of open proxies around the world (check today's load of spam for more addresses), there's going to be plenty of ways for perverts to get their fix once they learn these methods. Is the PA AG going to track all the open proxies out there, too?
But in either of these cases, there isn't much the ISP can do without the list. And I didn't see anything in the text of the law that says the list has to be held in strict confidence by the ISP (as if that would apply to an out of state ISP anyway).
Yes I have dealt with NAT. And no, it isn't easy. And yes, having IPv6 would make things easier.
But put blame where blame is due, on the IPv6 development and deployment. There are two fundamental problems. One is the routing architecture development didn't keep up, and two, there is no incentive being created to migrate to IPv6. Don't expect most ISPs to care to do anything within IPv6 until there is a real incentive. Of course the biggest incentive would be a return on investment. Other incentives would be to make it free. For example, give away free, permanent, and portable IPv6 space to just enough early adopters (who will be required to deploy it within a fixed time frame to keep it, such as 3 months, and tunneling OK until their upstream deploys direct IPv6 routing) to create enough critical mass to bring everyone else on board. And don't whine about the routing not being scalable enough to handle this because I am not proposing that everyone get this free, permanent, and portable space ... just the early adopters ... just enough to create the critical mass. Then at some point no more freebies will be available (it then goes back to justfied need).
Why should I bother to deploy IPv6 when I can't get portable space? That's the biggest thing I need right now. And it's NOT an issue of renumbering machines when I change upstream providers. Instead, it's an issue of dealing with all the references to fixed address references in other deployed systems, documentation, distributed material, etc, where the benefit of LAN prefixing isn't there. I do wish domain names covered everything, but unfortunately that simply isn't the case (try putting domain names in place of IP addresses in your /etc/resolv.conf file, for example, especially on a system burned into a CD-ROM).
It's the IPv6 promoters that need to get their heads out of the sand.
So if I lived in some poor third world country, and happened to have just enough money to buy some legal, non-pirated, commercial software, imported from some big industrialized nation with a huge IT sector, then ... I couldn't spend that money on something else like feeding my children. Do these idiots at BSA think that when people don't spend money on something like software, that they end up just burning it as cooking fuel?
The reality is the cause and effect is the other way around. Piracy always exists, and it mostly exists among those who don't have much to lose if they get caught, or are sure they won't get caught, or just don't have the money to buy it in the first place. It's the existance of a strong IT sector that generates market for software, which in turn generates revenues for those who sell it (domestically or internationally).
The message BSA should be sending out is:
There's plenty of address space remaining in IPv4 right now. Sure, it will eventually run out if nothing replaces it. That was originally projected to happen even before 2000. Now it looks like it won't be until after 2012 or 2015 or so. In the mean time, no incentive to switch to IPv6. But there is time to go back to the drawing table and redo the architecture right this time and include a scalable routing system. And yes, I have already thought out a way to do it (but I'm not in the elite circle of RFC writers, so they will just have to figure it out on their own, if they can).
Yes, I know it is a routing issue. In the panic (FUD) of imminent IPv4 exhaustion, the developers completely ignored the needed routing scaling issues. They were so worried about getting enough addresses, they didn't bother to make sure they would be fully usable. Likely the problem was that they were in such a hurry, they just didn't have time to do the research to make a scalable routing architecture to go along with it. That's such a shame, too.
BTW, all your description of what would be wrong with routing with millions of portable networks in IPv6 is based on the existing antiquated routing architecture the internet is currently running on (BGP4), and it's 128-bit version for IPv6 which doesn't really add any scalability (just adds longer prefixes and a few new functions).
The problem is, I already have hundreds of clients running systems with /etc/resolv.conf pointing to my DNS servers. I've already had to update those once, and it was a royal pain. Fortunately I had a 4 month overlap window where I was running on both the old and new address spaces at the same time.
Portability of IP address space is not about changing your IP address on the computers on that network; it's about changing the references to those addresses that would be present on machines outside of the network. And those have to be a full reference, including the prefix. DNS servers come to mind as one example where the address is mandatory. The actual renumbering of the servers on the network is trivial. I've done it so many times that's not a problem. The problem is in changing the references.
No, IPv4 won't last forever. But things like NAT and private addresses have definitely extended its life. Maybe even long enough to get a decent new IP architecture with scalable routing.
But that address space won't work when I switch provider. I get my IPv4 address spaces from my provider now, and they have the same problem, and IPv6 isn't solving it. I can't get a big portable allocation of IPv4 because IPv4 would run out if they did that. IPv6 won't, but they still won't give out portable address space because they forgot to deal with the routing issue. So now they've got this "spruce goose" of a new IP architecture which is probably going to have to be replaced anyway to do a universal portable routing architecture correctly. Not only do I not see any benefit to deploying IPv6, I even see costs which will likely be incurred over the next decade as they discover that all this was a waste of time, hurried along because of a sudden panic over fears of IPv4 space exhaustion (fears that were initially valid, but were also well dealt with).
Part of the problem goes all the way back to the flaws in the original requirements for IPv6. The flaw is that IPv6 was intended only to add address space, and not deal with the more serious scaling issue of routing. Unfortunately, routing is a complex problem which just doesn't readily fit into the kinds of address space technology both IPv4 and IPv6 are based on. The problem with routing the way it is done now is that every autonomous system has to be represented with the prefix of their address space in the routing table of every backbone router. So now we take routers which are expected to handle millions of packets a second and require them to store millions of route entries (this would be the case if everyone gets their own portable address space). Even though IPv6 has enough address space to give everyone in the world billions of addresses, they have no intent to ever do this on a permanent basis because they didn't think about the routing scaling issues before they jumped the gun and made yet another flat address model.
I seriously doubt it. It's a chickend and egg problem. Most companies are avoiding upgrades, patches, and service packs on just about everything. And you expect them to suddenly embrace IPv6 for no reason (what can they do that IPv4 can't do?)? Will there be anyone who will be running reachable only via IPv6? Well, a few geek sites will be there, but nothing for real world business and the average consumer. So no need for IPv6 and no desire for IPv6-only. It's DOA.
So IPv6 will cost $. So what's the incentive to deploy IPv6 if it costs $ and doesn't return any? Welcome to the capitalist world where everyone expects a return on investment. The only incentive to do IPv6 is the "geek factor" and 6bone is about to eliminate that.
Why do they need to be on IPv6? Hell, even Slashdot won't qualify for permanent IPv6 address space. One reason is that everyone has IPv4. When there are finally some people who are on IPv6-only, then it will be time to get Slashdot and other places on IPv6 (in addition to staying on IPv4).
It's not about whether IPv6 is going away or not. Obviously it's here to stay. But unless the IPv6 folks get their heads out of the sand, it will stay ... dormant. Give me a reason to be an early (e.g. before there are IPv6-only users) deployer of IPv6. And no, I don't mean on some limited tunnel network; I mean real natively routed IPv6 with my very own IPv6 address space (there's plenty of it to go around now in case you haven't noticed, although it sure seems a lot of people haven't).
Still, SUN machines of the desktop category are better hardware than commodity PCs. Maybe there are some exceptions, or at least some machines which come very close. But they will probably be as expensive, if not more so. The point is there is justification to buy SUN Sparc hardware for things on the "low end" such as desktops. Much of that market needs Solaris for many reasons. But not all of it. Linux is justified in many cases. Of those, some may just run Solaris anyway. Others may just run Intelish PCs anyway. SUN loses the business of the latter group to some extent, and others run Linux anyway, but not at the full capacity because of poor SUN support (e.g. they can't use StarOffice).
Too bad you can't comment on Linux on Sparc. That's my whole issue. And that's why I no longer recommend SUN machines to anyone except the high end enterprise class servers (and even then not in all cases, as some are better off with IBM S/390, a high end 5+ 9's machine for which Linux support does exist, but for which a desktop market is entirely absent). What I want is a highly reliable 64-bit desktop Linux that's not based on an Intel x86. What do you suggest to get that?
"SUN" is an acronym for Stanford University Networks, the original name of the company. It's not shouty caps.
Given that IPv4 space is no longer at risk of being exhausted, there is virtually no real incentive to switching to IPv6. The only one that exists right now is the "geek factor", a measure of "coolness" recognized only by other geeks (and then, most of those are now considering it to be boring).
Had the IPv6 proponents really wanted to get more people to switch to IPv6, they would have wised up and offered something substantial. Free IPv6 addresses in the 6bone that were never intended to be permanent simply brought out just a small limited response. But if they had offered real permanent addresses, maybe a lot more people would have responded.
Although IPv4 space is no longer at risk of running out, it does have limitations that prevent any substantial portable address space from being allocated to all who want it. IPv6 has that space. There is no excuse for not doing so. But the IPv6 people are trying to make using IPv6 hard by their absurd policies. They have no one to blame but themselves why so many are not migrating to IPv6.
I do have IPv4 space. For places potentially running only IPv6, there will be the IPv4 equivalency range of IPv6 which I can use. But I won't have any reason to deploy that until after there are a substantial number of IPv6-only locations. Of course, no one will want to have only IPv6 until enough reachability exists in IPv6. Chicken. Egg.