Phones aren't that important. Travelling internet connections on the other hand are incredibly useful. Less than 1/10th of the time I use my iPhone has a call active, quite possibly less than 1/50th. So who cares how bad it is as a phone? It's good enough that it isn't worth carrying another device for those 5 minutes of talk time a day -- and texting is actually better on a good smartphone than on a non-smartphone.
In fact I had my iPhone for months before unlocks appeared, so I didn't have a SIM in it.
So far, Google's kept it, and HP lost it long ago.
If you mean the company which should be called Compaq, it has never been particularly innovative. The real HP is now called Agilent. I don't use their products, but other people say they are innovative still.
Self-signed certificates should be allowed for URL's starting with http:/// not URL's starting with https://./ Unfortunately HTTP does not present a greeting from the server to the client (unlike SMTP), so you cannot advertise support for encryption in HTTP. That's why it's necessary to convey this out-of-band which is done in HTTPS by switching to a different port.
They are generally just electrically assisted bicycles. Around here they are limited so that the electric motor adds less power at higher speeds and shuts off completely at 25kph. They are allowed in bicycle lanes and have almost the same handling characteristics and looks as regular bicycles, and you can drive them without needing a license.
100MPH+ crashes are fairly common in Formula 1. The driver almost universally survives. In fact, the last Formula 1 fatality happened in 1994. This material might be too heavy to work for Formula 1, but if it can give other cars a bit of the same safety, I'm all for it. If the car magically springs back into shape after a crash, so much the better.
This is kind of the other way around from the Osborne. The Osborne 2 was supposed to be better in every way than the Osborne 1. In this case, the next Tesla model is going to be inferior to the Roadster in every aspect except price and space. So everyone who wants the real thing should buy before 2011, or they won't get one (new) at all.
You're quoting a document from 1999... Back then it was assumed that sites would not have provider-independent addresses, because site renumbering would be really really easy, and multihoming would be handled by new clever protocols.
Well renumbering is a lot easier with IPv6, but it still isn't easy. Multihoming solutions never materialized. So in the end it was decided to just go ahead and allow provider-independent addresses in much the same way as IPv4, which forced address assignment rules to be adjusted.
That work around has the nasty side effect of increasing your DNS load by an exponential factor, which isn't good either.
Imagine you're hosting web servers. If you can handle N HTTP queries, you can also handle N DNS requests, unless your DNS servers are completely useless. Even with TTL 0, you'll only get at most the same number of DNS requests as you're getting HTTP queries.
In that case, you're really getting multiple TLAs, which isn't really the same as subnetting per the RFCs.
This makes no sense. If you get a/48 you get 65536 subnets. If you get a/56 you only get 256 subnets. And if you manage to show the need for a/32, you get 2^32 subnets. In all cases the actual subnet "mask" is/64 (with the caveats about non-/64-subnets for routers mentioned earlier)
7/8ths of all IPv6 address space has been reserved for just that eventuality. Should the current policies prove too wasteful, we'll have to allocate another 7/8th and be more careful. Hopefully that won't happen 7 times.
Good point, TTL inspection would catch anyone using a router (NAT or not). However, you can't use a non-NAT-router with just 1 IP address anyway, so that's a bit of a theoretical concern.
The first 64-bits are the "network" portion of the address, and the second 64-bit chunk is the interface portion (ie the ipv6 version of your mac address). I'm ignoring multicast for the present. For normal unicast, you can't subnet smaller than a/64.
It may not be allowed, but it is widely deployed. Not with hosts in those subnets, but it is fairly popular with router-only subnets.
If your ISP is following the standard, they can't give you bigger than a/48 for your site.
If you can demonstrate need, you can get up to a/32 even as a non-ISP. Obviously demonstrating the need for such a large allocation is a bit theoretical.
No, that is not allowed (well the police won't stop them, but it's definitely not best practice). Best practice was originally a/48, but now ISP's are allowed to cut all the way down to a/56 if they feel a/48 is too much.
You shouldn't put hosts in anything but a/64, and some don't think there should exist non-/64 unicast networks at all. Personally I believe that at least/128 should be allowed.
Not entirely true. Most phone companies have anti-fraud systems and will detect and possibly disconnect you if you suddenly make 1000 times as many calls as usual. Compare with making a thousand new connections a minute to TCP port 25.
If they can't afford to keep their machine clean, they don't go on the Internet. Sucks to be them. They don't get to pass on the cost of their mistakes to everyone else, like they do if you just keep their connection alive.
Yes I work for an ISP. Yes that's in our terms and conditions.
Operating systems are ready. Many applications are ready. DNS is ready, resolver libraries are ready. What is missing is the core Internet, precisely the people who should have been reading RFC's. Well that and CPE's, but those are just a firmware upgrade away, and ISP's seem to handle those fine.
If IPv6 had been designed to allow IPv6-capable devices to connect across a partially IPv4 path, we would have been fine. This is what using an IP routing option would have given us (with NAT done when going IPv6 to IPv4 and back). It would also have allowed e.g. IPv6 browsers to connect to IPv4 web servers.
Of course it wasn't obvious at the time that the problem would be ISP's and core router vendors dragging their feet.
Paypal is notorious for not getting the abuse checks right.
If we assume an email fee of one penny (highly unlikely though, because even a dedicated service without abuse checks would require that much just as a transaction fee), $10 would give the spammer a thousand emails to send. All of which would be delivered to the recipients, since that's the whole point of this system. I bet that's comparable to their current success rate, where 99.9% of their spams are caught by filters.
At the recipient end I'd be stuck with a thousand emails to read for a pay of $10, which is just not acceptable.
Slashdot Mirror
Phones aren't that important. Travelling internet connections on the other hand are incredibly useful. Less than 1/10th of the time I use my iPhone has a call active, quite possibly less than 1/50th. So who cares how bad it is as a phone? It's good enough that it isn't worth carrying another device for those 5 minutes of talk time a day -- and texting is actually better on a good smartphone than on a non-smartphone.
In fact I had my iPhone for months before unlocks appeared, so I didn't have a SIM in it.
They said that before World War I too.
I tried to verify this statement, but all the search results seem to be from after World War I.
So far, Google's kept it, and HP lost it long ago.
If you mean the company which should be called Compaq, it has never been particularly innovative. The real HP is now called Agilent. I don't use their products, but other people say they are innovative still.
since SSD drives in fact ARE DRAM!
No. DRAM doesn't keep state across power loss, and it's a lot more expensive, just like the OP said.
Netbooks come with 160GB or 250GB hard drives. To me that's big storage; I have an 80GB SSD in my laptop which tends to be enough.
Self-signed certificates should be allowed for URL's starting with http:/// not URL's starting with https://./ Unfortunately HTTP does not present a greeting from the server to the client (unlike SMTP), so you cannot advertise support for encryption in HTTP. That's why it's necessary to convey this out-of-band which is done in HTTPS by switching to a different port.
They are generally just electrically assisted bicycles. Around here they are limited so that the electric motor adds less power at higher speeds and shuts off completely at 25kph. They are allowed in bicycle lanes and have almost the same handling characteristics and looks as regular bicycles, and you can drive them without needing a license.
100MPH+ crashes are fairly common in Formula 1. The driver almost universally survives. In fact, the last Formula 1 fatality happened in 1994. This material might be too heavy to work for Formula 1, but if it can give other cars a bit of the same safety, I'm all for it. If the car magically springs back into shape after a crash, so much the better.
This is kind of the other way around from the Osborne. The Osborne 2 was supposed to be better in every way than the Osborne 1. In this case, the next Tesla model is going to be inferior to the Roadster in every aspect except price and space. So everyone who wants the real thing should buy before 2011, or they won't get one (new) at all.
You're quoting a document from 1999... Back then it was assumed that sites would not have provider-independent addresses, because site renumbering would be really really easy, and multihoming would be handled by new clever protocols.
Well renumbering is a lot easier with IPv6, but it still isn't easy. Multihoming solutions never materialized. So in the end it was decided to just go ahead and allow provider-independent addresses in much the same way as IPv4, which forced address assignment rules to be adjusted.
You can't reliably anycast TCP. The session might switch servers in the middle.
That work around has the nasty side effect of increasing your DNS load by an exponential factor, which isn't good either.
Imagine you're hosting web servers. If you can handle N HTTP queries, you can also handle N DNS requests, unless your DNS servers are completely useless. Even with TTL 0, you'll only get at most the same number of DNS requests as you're getting HTTP queries.
In that case, you're really getting multiple TLAs, which isn't really the same as subnetting per the RFCs.
This makes no sense. If you get a /48 you get 65536 subnets. If you get a /56 you only get 256 subnets. And if you manage to show the need for a /32, you get 2^32 subnets. In all cases the actual subnet "mask" is /64 (with the caveats about non-/64-subnets for routers mentioned earlier)
7/8ths of all IPv6 address space has been reserved for just that eventuality. Should the current policies prove too wasteful, we'll have to allocate another 7/8th and be more careful. Hopefully that won't happen 7 times.
Good point, TTL inspection would catch anyone using a router (NAT or not). However, you can't use a non-NAT-router with just 1 IP address anyway, so that's a bit of a theoretical concern.
What is wrong with protocol-based packet inspection?
Because you aren't supposed to ever worry about the lower 64 bits. They just magically acquire reasonable values, like in IPX.
The first 64-bits are the "network" portion of the address, and the second 64-bit chunk is the interface portion (ie the ipv6 version of your mac address). I'm ignoring multicast for the present. For normal unicast, you can't subnet smaller than a /64.
It may not be allowed, but it is widely deployed. Not with hosts in those subnets, but it is fairly popular with router-only subnets.
If your ISP is following the standard, they can't give you bigger than a /48 for your site.
If you can demonstrate need, you can get up to a /32 even as a non-ISP. Obviously demonstrating the need for such a large allocation is a bit theoretical.
No, that is not allowed (well the police won't stop them, but it's definitely not best practice). Best practice was originally a /48, but now ISP's are allowed to cut all the way down to a /56 if they feel a /48 is too much.
You shouldn't put hosts in anything but a /64, and some don't think there should exist non-/64 unicast networks at all. Personally I believe that at least /128 should be allowed.
But there is. For one thing the TTL will be one lower than "usual". You can hide that, but there are lots of other ways to detect it.
Not entirely true. Most phone companies have anti-fraud systems and will detect and possibly disconnect you if you suddenly make 1000 times as many calls as usual. Compare with making a thousand new connections a minute to TCP port 25.
If they can't afford to keep their machine clean, they don't go on the Internet. Sucks to be them. They don't get to pass on the cost of their mistakes to everyone else, like they do if you just keep their connection alive.
Yes I work for an ISP. Yes that's in our terms and conditions.
Operating systems are ready. Many applications are ready. DNS is ready, resolver libraries are ready. What is missing is the core Internet, precisely the people who should have been reading RFC's. Well that and CPE's, but those are just a firmware upgrade away, and ISP's seem to handle those fine.
If IPv6 had been designed to allow IPv6-capable devices to connect across a partially IPv4 path, we would have been fine. This is what using an IP routing option would have given us (with NAT done when going IPv6 to IPv4 and back). It would also have allowed e.g. IPv6 browsers to connect to IPv4 web servers.
Of course it wasn't obvious at the time that the problem would be ISP's and core router vendors dragging their feet.
Paypal is notorious for not getting the abuse checks right.
If we assume an email fee of one penny (highly unlikely though, because even a dedicated service without abuse checks would require that much just as a transaction fee), $10 would give the spammer a thousand emails to send. All of which would be delivered to the recipients, since that's the whole point of this system. I bet that's comparable to their current success rate, where 99.9% of their spams are caught by filters.
At the recipient end I'd be stuck with a thousand emails to read for a pay of $10, which is just not acceptable.
SPF only protects the envelope from, not the "from" which is shown to the user.