On Nov 22, 2011, at 8:05 AM, Ray Soucy <r...@maine.edu> wrote: > As long as a static allocation can be billed as a premium service, > most providers will unfortunately do it.
Exactly. ISPs are in business to make as much money as they can - go figure. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. "Break the internet" is about how I'd phrase it. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). 8) Don't use the "wrong" ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination.
