I had a college roommate who couldn't pay the minimum amount due on his credit cards. His solution: relieve the stress by charging a $300 car stereo.
For every person locked in to the underclass by circumstances beyond their control there are ten more who every day make the choices that keep them there. You can save the one with cash and a little education will help a couple of the ten. Throw resources at the rest and you'll only learn how to squander your money the way they do.
Math and maths both being short for mathematics. I guess it depends on whether you consider mathematics to be a science (ergo singular) or a group of sciences (ergo plural).
In other news, Computer Science researchers discover that O(n^n) problems reduce to O(1) given the availability of n^n comptuers working in parallel.
I would note, however, that a more useful result does exist: many O(n log n) problems reduce to O(n) given the availability of log n processors. As log n is generally small this requires only a trivial application of parallelism. Merge sort, one of the staples of database engines, is a good example.
And if my way does all that, it will doubtless remain wrong for some other reason because your way is right and there can't be two opposing right answers.
Like I said, its a conceit. Its more likely to reflect some combination of inexperience and inability to distinguish between opposing ideas that are in error versus opposing ideas that are merely inconvenient to your way of thought.
Can't be very efficient. The combination of pressure and refrigeration necessary to keep hydrogen liquified is excessive. The car will consume a lot of energy while idle, just to keep the stored hydrogen from explosively evaporating into a gas.
On the other hand, if the cost and environmental impact of producing electricity could be reduced by 90% that might not be such a bad deal.
Specifically, its caching of DNS lookups IN VIOLATION OF the DNS protocol standard for TTL. This causes all manner of havoc when you change ISPs and need the old name/address mappings to quickly expire. I've seen Windows boxen continue to poll the old IP address for a web site weeks after the lookup with a 5-minute TTL was changed to the new IP address.
Pinning is bad bad bad and any application so poorly designed that it needs pinning to work securely is worse. If Javascript can't operate securely using DNS in the standard way, don't allow it to use DNS at all.
If you haven't read the article, I'll summarize it for you: its another critical vulnerability in java/javascript. The sandboxed script in the web browser alternately makes GET and POST requests the "same" server with each POST containing the contents of the prior GET... Only the IP address associated with the server's hostname keeps alternating between a server inside your firewall and the attacker's real server outside it. Oops.
At times like these, I tell a story about 1988 when I wrote a BBS terminal emulator for the Commodore 64 which cleverly allowed the BBS to send and run new code on the caller's machine. Another gentleman who didn't much like me noticed the feature and arranged for a number of BBS systems to execute the code at location 64738: system reset.
There is no safe way to run complex sandboxed code on a user's PC and no safe way to allow sandboxed code access to the network. Either you trust the source of the program and let it do what it needs to do, or you don't trust it and don't allow it to run on your PC at all. How many of these vulnerabilities are we going to run through before we finally figure that out?
A license is not a type of contract, at least not in the USA.
If you want to get technical about it, the GPLv3 is both a license and a license agreement.
As a license, its a property (similar to a copyright) which entitles its owner to perform certain actions not otherwise permitted by law, such as making copies of the covered copyright.
As a license agreement, its a contract tendered by the owners of the copyright which offers a license to any takers provided they agree to the terms.
Practically speaking, there's no difference. Microsoft has publicly rejected the tendered offer of a license. Accordingly they are neither bound by the GPLv3 nor have they received any rights under the GPLv3. If you think they're using code covered under GPLv3 and own the copyrights, feel free to sue them for copyright infringement. Don't waste your time alleging license violations though... They never accepted the contract which would have conferred a license.
Are you absolutely sure you will continue to remain qualified under whatever procedures and policies are adopted to conserve IPv4 address and routing table space?
Yes. Yes I am. I keep up with ARIN PPML and NANOG and I've run the back-of-the-napkin calculations. There simply aren't any likely scenarios in which its more cost-effective to cut me off than it is to buy YFRV's next router. There aren't any scenarios where its even close enough to consider.
If you disagree, feel free to suggest a scenario so I can debunk it.
Is it? I thought you just got through explaining why it wouldn't be good for everybody.
Touche! Obviously I meant that its good for the folks who aren't in my position if the folks who are in my position don't hold up the wide deployment of IPv6.
Then, we'd have an IPv6 address crunch hit us just like the IPv4 crunch that looms over us now.
The IPv6 address space is more than 28 orders of magnitude larger than the IPv4 address space. More really when you consider how much of the IPv4 space has been lost for stupid reasons (coughmulticastcough). I don't think any of us has fully come to grips with exactly how large the IPv6 space is.
The number of legacy IPv4 registrants who announce IPv4 addresses but don't qualify for IPv6 addresses is well under 50,000. Fair or not, a one-time hit to the address space and DFZ table isn't going to hurt anybody.
The only IPv6 crunch likely in anything approaching the near term is a DFZ-size crunch. That could be handled with something like: http://bill.herrin.us/trrp.html
How will deployment of IPv6 make your existing IPv4 network less useful?
a. If my network is multihomed via IPv4 but not multihomed via IPv6 then it is less reliably and efficiently reachable via IPv6.
b. Routing table size concerns offer a strong motivation for network operators to deprecate IPv4 once a critical mass of deployment of IPv6 has occured. While such deprecation will not eliminate IPv4, it will reduce the reliability and efficiency of IPv4 routing overall.
c. If IPv4 reliability and efficiency is reduced overall then it is also reduced for my IPv4 network.
d. If the reliability and efficiency for my IPv4 network falls and the reliability and efficiency of my IPv6 network was lower in the first place due to no multihoming then the overall reliability and efficiency of access to my network falls.
d. My deployment of IPv6 helps IPv6 achieve its critical mass.
e. Therefore my deployment of IPv6 without multihoming helps bring about the situation where my network is less reliably and efficiently reachable.
q.e.d.
At some point, it won't be any easier to qualify for multihoming on IPv4 than it will be to qualify for PI space in IPv6.
I don't have to qualify for IPv4 multihoming; I already have it.
Just because there are 128 bits of address space is no reason to start handing out PI prefixes like candy
You're right. The reason to hand them out like candy is because its good for everybody if IPv6 is widely deployed before IPv4 depletion. That there are 128 bits in the address plays no role at all.
That's why we have PA addresses in the first place. At least, you should be able to get those without too much trouble.
The problem is: I'm not actually an idiot. I understand perfectly well that if current policy prevails, I will be unable to make use of multihoming once IPv6 becomes dominant. As a result, deployment of IPv6 will make my network less useful. Why would I encourage and enable that result?
If the problem is that the RIRs are trying too hard not to give away the store to the early adopters (like was done with IPv4 back in the day), then that's a problem to take up with the RIRs, not the IETF.
I agree. How about you jump on the ARIN PPML list and announce your support for one of the proposals that would accomplish just that?
Fortunately or unfortunately, depending on your viewpoint, there aren't going to be all that many people in a situation such as that (in the overall scheme of things).
Its not a question of quantity; its a question of quality. Many of the folks who got in early enough to get legacy space now hold senior-level positions at major Internet companies. How eager do you think I am to organize an IPv6 deployment on the big network when I've been dismissed as insignificant on my little network?
That's nice but your hosts still have to add up to around 500 actual pieces of hardware before you meet the policy requiresments to get space. If you fudge as much as possible without lying outright you can get that down to about 200.
I have 20 hosts multihomed using legacy address space. I don't need many addresses, but I do need for them to be multihomed. That means IPv6 PI space. Which I can't get.
I won't diss 6to4. Its a good idea that could have been great but for network operator resistance to accepting the IPv6 routes as native annoucements. (The RFC forbids it due their objections.)
But no, what I want is what I said I want: to configure my IPv6 hosts with my old IPv4 addresses and have them interact with everybody else doing the same as well as the old IPv4-only hosts who can't, right up until the moment where the IPv4 addresses run out and we have to start allocating IPv6 addresses which aren't able to talk to the IPv4 only hosts.
Unfortunately, that concept was abandoned early in IPv6's development and is now impossible to do.
And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.
I doubt much breaks. The only thing likely to break with multiple nats is peer to peer. If the small fraction of Internet users who want peer to peer have to pay an extra $2/month for a "public IP address," its not enough pain to push IPv6. In fact, its an extra revenue source for the ISP.
Besides, think of the ISP FAQ....
Q. How does the switch from public IP addresses to private IP addresses affect me?
A. Its a free firewall because we care about you. Hackers and worms will be unable to infect your computer when it no longer uses a public IP address.
While multi-homing is important for highly reliable connectivity, we need to do some better aggregating of it. PI blocks should be limited to only those businesses so large that they can't operate as part of a group collective. Smaller businesses that do need multi-homing (as opposed to redundant connectivity to one provider that has multi-homing) can group together to use a common PI block divided into subnets and thus use cause one route entry for the lot of them.
Show me how to actually do that from a technical perspective that doesn't also require them to negotiate Internet transit as a group and you win the prize.
That's funny, because I have a multihomed network in North America and my RIR (ARIN) won't assign me PI space. It seems my network is just too small and insignificant...
No, 2002:: is for 6to4. You map the IPv4 address in right after the 2002 and the machine at that IPv4 address serves as the gateway to a/48 of IPv6 addresses. For example, if your 6to4 gateway's IPv4 address is a.b.c.d then its IPv6 address is 2002:aabb:ccdd::1 and it supplies IPv6 connectivity for 2002:aabb:ccdd::/48.
6to4 is a good idea that could be great but isn't because it depends on a small network of volunteers to run encapsulators and decapsulators. The volunteers would be overrun if any meaningful business use was attempted.
At the risk of extending a longstanding argument, the article reads:
IPv4 mapped addresses are normally used by the IP stack to represent IPv4 addresses to IPv6 applications. It allows the transparent use of transport layer protocols (TCP or UDP) over IPv4 through the IPv6 networking API.
In other words, it is not a mechanism by which IPv4 software and hosts can use IPv6. It is instead a mechanism by which IPv6 software on dual-stack hosts can use IPv4. I can't just plop down a special router and poof my IPv4-only hosts can interoperate with your IPv6-only hosts at least until we run out of IPv4 addresses.
This has been a hot topic on a number of lists. Some observations:
1. Neither John Curran nor the IETF has the the authority to bring this about, thus the use of the word "must" is misleading. Even if the regional internet registries supported this with policy that placed additional IPv4 addresses out of reach of those who did not deploy IPv6, far less than half of the content providers would be impacted within the proposed timeframe. Indeed, relatively few content providers come back for more addresses. Its mostly the transit providers which connect the end users who have a growing need for IP addresses.
2. The natural course of IPv4 depletion is more likely to drive conservation of IPv4 addresses than it is to drive IPv6 adoption. Business will tend towards this path because the incremental cost of conservation is small and the benefits are immediate while the cost of IPv6 deployment is large and the benefits are remote. Conservation might sound like a good thing but its actually very dangerous. It implies injecting many additional routes into the "default-free zone," which for complex technical reasons would decrease the overall stability of the Internet.
3. Existing policy at the regional registries serves to obstruct the deployment of IPv6. For example, in the Americas at ARIN, there is an additional $500 fee to receive IPv6 addresses in addition to whatever fees you pay for IPv4 addresses. That's a nuissance. More critical is the wide swath of legacy multihomed content providers who because they are too small don't qualify for IPv6 addresses from ARIN. Those folks can't get the so-called "provider-independent" addresses they need to connect via IPv6 in a technically comperable way to how they connect with IPv4.
Slashdot Mirror
Prediction: IBM will be the principal debt holder at SCO's bankruptcy liquidation.
You heard it here first.
I had a college roommate who couldn't pay the minimum amount due on his credit cards. His solution: relieve the stress by charging a $300 car stereo.
For every person locked in to the underclass by circumstances beyond their control there are ten more who every day make the choices that keep them there. You can save the one with cash and a little education will help a couple of the ten. Throw resources at the rest and you'll only learn how to squander your money the way they do.
Math and maths both being short for mathematics. I guess it depends on whether you consider mathematics to be a science (ergo singular) or a group of sciences (ergo plural).
In other news, Computer Science researchers discover that O(n^n) problems reduce to O(1) given the availability of n^n comptuers working in parallel.
I would note, however, that a more useful result does exist: many O(n log n) problems reduce to O(n) given the availability of log n processors. As log n is generally small this requires only a trivial application of parallelism. Merge sort, one of the staples of database engines, is a good example.
And if my way does all that, it will doubtless remain wrong for some other reason because your way is right and there can't be two opposing right answers.
Like I said, its a conceit. Its more likely to reflect some combination of inexperience and inability to distinguish between opposing ideas that are in error versus opposing ideas that are merely inconvenient to your way of thought.
Can't be very efficient. The combination of pressure and refrigeration necessary to keep hydrogen liquified is excessive. The car will consume a lot of energy while idle, just to keep the stored hydrogen from explosively evaporating into a gas.
On the other hand, if the cost and environmental impact of producing electricity could be reduced by 90% that might not be such a bad deal.
it's the caching of DNS lookups
Specifically, its caching of DNS lookups IN VIOLATION OF the DNS protocol standard for TTL. This causes all manner of havoc when you change ISPs and need the old name/address mappings to quickly expire. I've seen Windows boxen continue to poll the old IP address for a web site weeks after the lookup with a 5-minute TTL was changed to the new IP address.
Pinning is bad bad bad and any application so poorly designed that it needs pinning to work securely is worse. If Javascript can't operate securely using DNS in the standard way, don't allow it to use DNS at all.
If you haven't read the article, I'll summarize it for you: its another critical vulnerability in java/javascript. The sandboxed script in the web browser alternately makes GET and POST requests the "same" server with each POST containing the contents of the prior GET... Only the IP address associated with the server's hostname keeps alternating between a server inside your firewall and the attacker's real server outside it. Oops.
At times like these, I tell a story about 1988 when I wrote a BBS terminal emulator for the Commodore 64 which cleverly allowed the BBS to send and run new code on the caller's machine. Another gentleman who didn't much like me noticed the feature and arranged for a number of BBS systems to execute the code at location 64738: system reset.
There is no safe way to run complex sandboxed code on a user's PC and no safe way to allow sandboxed code access to the network. Either you trust the source of the program and let it do what it needs to do, or you don't trust it and don't allow it to run on your PC at all. How many of these vulnerabilities are we going to run through before we finally figure that out?
generalist who will figure out the right way to code it the first time
Maybe not "the right way." That's a conceit common to our profession: that our way is "right." But at least a GOOD way to code it.
A license is not a type of contract, at least not in the USA.
e ement
If you want to get technical about it, the GPLv3 is both a license and a license agreement.
As a license, its a property (similar to a copyright) which entitles its owner to perform certain actions not otherwise permitted by law, such as making copies of the covered copyright.
As a license agreement, its a contract tendered by the owners of the copyright which offers a license to any takers provided they agree to the terms.
Practically speaking, there's no difference. Microsoft has publicly rejected the tendered offer of a license. Accordingly they are neither bound by the GPLv3 nor have they received any rights under the GPLv3. If you think they're using code covered under GPLv3 and own the copyrights, feel free to sue them for copyright infringement. Don't waste your time alleging license violations though... They never accepted the contract which would have conferred a license.
http://en.wikipedia.org/wiki/Software_license_agr
Clearly YANAL. If you were, you'd know that a software license (like GPLv3) is a type of contract.
Are you absolutely sure you will continue to remain qualified under whatever procedures and policies are adopted to conserve IPv4 address and routing table space?
Yes. Yes I am. I keep up with ARIN PPML and NANOG and I've run the back-of-the-napkin calculations. There simply aren't any likely scenarios in which its more cost-effective to cut me off than it is to buy YFRV's next router. There aren't any scenarios where its even close enough to consider.
If you disagree, feel free to suggest a scenario so I can debunk it.
Is it? I thought you just got through explaining why it wouldn't be good for everybody.
Touche! Obviously I meant that its good for the folks who aren't in my position if the folks who are in my position don't hold up the wide deployment of IPv6.
Then, we'd have an IPv6 address crunch hit us just like the IPv4 crunch that looms over us now.
The IPv6 address space is more than 28 orders of magnitude larger than the IPv4 address space. More really when you consider how much of the IPv4 space has been lost for stupid reasons (coughmulticastcough). I don't think any of us has fully come to grips with exactly how large the IPv6 space is.
The number of legacy IPv4 registrants who announce IPv4 addresses but don't qualify for IPv6 addresses is well under 50,000. Fair or not, a one-time hit to the address space and DFZ table isn't going to hurt anybody.
The only IPv6 crunch likely in anything approaching the near term is a DFZ-size crunch. That could be handled with something like: http://bill.herrin.us/trrp.html
How will deployment of IPv6 make your existing IPv4 network less useful?
a. If my network is multihomed via IPv4 but not multihomed via IPv6 then it is less reliably and efficiently reachable via IPv6.
b. Routing table size concerns offer a strong motivation for network operators to deprecate IPv4 once a critical mass of deployment of IPv6 has occured. While such deprecation will not eliminate IPv4, it will reduce the reliability and efficiency of IPv4 routing overall.
c. If IPv4 reliability and efficiency is reduced overall then it is also reduced for my IPv4 network.
d. If the reliability and efficiency for my IPv4 network falls and the reliability and efficiency of my IPv6 network was lower in the first place due to no multihoming then the overall reliability and efficiency of access to my network falls.
d. My deployment of IPv6 helps IPv6 achieve its critical mass.
e. Therefore my deployment of IPv6 without multihoming helps bring about the situation where my network is less reliably and efficiently reachable.
q.e.d.
At some point, it won't be any easier to qualify for multihoming on IPv4 than it will be to qualify for PI space in IPv6.
I don't have to qualify for IPv4 multihoming; I already have it.
Just because there are 128 bits of address space is no reason to start handing out PI prefixes like candy
You're right. The reason to hand them out like candy is because its good for everybody if IPv6 is widely deployed before IPv4 depletion. That there are 128 bits in the address plays no role at all.
That's why we have PA addresses in the first place. At least, you should be able to get those without too much trouble.
The problem is: I'm not actually an idiot. I understand perfectly well that if current policy prevails, I will be unable to make use of multihoming once IPv6 becomes dominant. As a result, deployment of IPv6 will make my network less useful. Why would I encourage and enable that result?
If the problem is that the RIRs are trying too hard not to give away the store to the early adopters (like was done with IPv4 back in the day), then that's a problem to take up with the RIRs, not the IETF.
I agree. How about you jump on the ARIN PPML list and announce your support for one of the proposals that would accomplish just that?
Fortunately or unfortunately, depending on your viewpoint, there aren't going to be all that many people in a situation such as that (in the overall scheme of things).
Its not a question of quantity; its a question of quality. Many of the folks who got in early enough to get legacy space now hold senior-level positions at major Internet companies. How eager do you think I am to organize an IPv6 deployment on the big network when I've been dismissed as insignificant on my little network?
That's nice but your hosts still have to add up to around 500 actual pieces of hardware before you meet the policy requiresments to get space. If you fudge as much as possible without lying outright you can get that down to about 200.
I have 20 hosts multihomed using legacy address space. I don't need many addresses, but I do need for them to be multihomed. That means IPv6 PI space. Which I can't get.
I won't diss 6to4. Its a good idea that could have been great but for network operator resistance to accepting the IPv6 routes as native annoucements. (The RFC forbids it due their objections.)
But no, what I want is what I said I want: to configure my IPv6 hosts with my old IPv4 addresses and have them interact with everybody else doing the same as well as the old IPv4-only hosts who can't, right up until the moment where the IPv4 addresses run out and we have to start allocating IPv6 addresses which aren't able to talk to the IPv4 only hosts.
Unfortunately, that concept was abandoned early in IPv6's development and is now impossible to do.
How we do prove that we are truly running out of IPv4 address?
That's pretty much been done: http://www.potaroo.net/tools/ipv4/index.html
And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.
I doubt much breaks. The only thing likely to break with multiple nats is peer to peer. If the small fraction of Internet users who want peer to peer have to pay an extra $2/month for a "public IP address," its not enough pain to push IPv6. In fact, its an extra revenue source for the ISP.
Besides, think of the ISP FAQ....
Q. How does the switch from public IP addresses to private IP addresses affect me?
A. Its a free firewall because we care about you. Hackers and worms will be unable to infect your computer when it no longer uses a public IP address.
What are you going to do? Threaten to hold your breath until you get your way?
More or less. My absence from the IPv6 network will cause a lot of others a lot of pain long before it causes me any.
While multi-homing is important for highly reliable connectivity, we need to do some better aggregating of it. PI blocks should be limited to only those businesses so large that they can't operate as part of a group collective. Smaller businesses that do need multi-homing (as opposed to redundant connectivity to one provider that has multi-homing) can group together to use a common PI block divided into subnets and thus use cause one route entry for the lot of them.
Show me how to actually do that from a technical perspective that doesn't also require them to negotiate Internet transit as a group and you win the prize.
That's funny, because I have a multihomed network in North America and my RIR (ARIN) won't assign me PI space. It seems my network is just too small and insignificant...
No, 2002:: is for 6to4. You map the IPv4 address in right after the 2002 and the machine at that IPv4 address serves as the gateway to a /48 of IPv6 addresses. For example, if your 6to4 gateway's IPv4 address is a.b.c.d then its IPv6 address is 2002:aabb:ccdd::1 and it supplies IPv6 connectivity for 2002:aabb:ccdd::/48.
6to4 is a good idea that could be great but isn't because it depends on a small network of volunteers to run encapsulators and decapsulators. The volunteers would be overrun if any meaningful business use was attempted.
What I don't understand is why the IPv4 address space isn't mapped conveniently into the IPv6 address space
It is.
http://en.wikipedia.org/wiki/IPv4_mapped_address
At the risk of extending a longstanding argument, the article reads:
IPv4 mapped addresses are normally used by the IP stack to represent IPv4 addresses to IPv6 applications. It allows the transparent use of transport layer protocols (TCP or UDP) over IPv4 through the IPv6 networking API.
In other words, it is not a mechanism by which IPv4 software and hosts can use IPv6. It is instead a mechanism by which IPv6 software on dual-stack hosts can use IPv4. I can't just plop down a special router and poof my IPv4-only hosts can interoperate with your IPv6-only hosts at least until we run out of IPv4 addresses.
This has been a hot topic on a number of lists. Some observations:
1. Neither John Curran nor the IETF has the the authority to bring this about, thus the use of the word "must" is misleading. Even if the regional internet registries supported this with policy that placed additional IPv4 addresses out of reach of those who did not deploy IPv6, far less than half of the content providers would be impacted within the proposed timeframe. Indeed, relatively few content providers come back for more addresses. Its mostly the transit providers which connect the end users who have a growing need for IP addresses.
2. The natural course of IPv4 depletion is more likely to drive conservation of IPv4 addresses than it is to drive IPv6 adoption. Business will tend towards this path because the incremental cost of conservation is small and the benefits are immediate while the cost of IPv6 deployment is large and the benefits are remote. Conservation might sound like a good thing but its actually very dangerous. It implies injecting many additional routes into the "default-free zone," which for complex technical reasons would decrease the overall stability of the Internet.
3. Existing policy at the regional registries serves to obstruct the deployment of IPv6. For example, in the Americas at ARIN, there is an additional $500 fee to receive IPv6 addresses in addition to whatever fees you pay for IPv4 addresses. That's a nuissance. More critical is the wide swath of legacy multihomed content providers who because they are too small don't qualify for IPv6 addresses from ARIN. Those folks can't get the so-called "provider-independent" addresses they need to connect via IPv6 in a technically comperable way to how they connect with IPv4.