On Nov 22, 2011, at 8:19 AM, Owen DeLong wrote:
>> Exactly. ISPs are in business to make as much money as they can - go figure.
> How do you make more money by refusing to meet customer requests?
Not rocket science. The vast majority of customers fall into a small number of
categories. You make money by optimizing for those categories. For the folks
that don't fit in those categories (e.g., people who actually ask for IPv6),
you treat them as special cases until there are sufficient requests to justify
a new category.
>> 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.
> That's beyond tragic if it's actually true. You should name and shame your
> provider if that's really the case.
I suspect most (all?) very large scale service providers amortize their
equipment over quite long periods. If said equipment doesn't support
<feature>, it becomes a relatively simple cost/benefit analysis to determine
whether or not upgrading the hardware out of cycle would have sufficient ROI to
justify the cost. A lot depends on how many customers will bolt if <feature>
isn't offered before the equipment is put out to pasture naturally. Since
(currently) the vast majority of large scale providers' customers have no
interest in (or even knowledge of) IPv6, it's unlikely the cost/benefit
analysis ends up in a pro-IPv6 way.
There are, of course, more forward looking ISPs, but they appear to be the
exception rather than the rule.
>> 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).
> This hasn't been my experience unless you're behind some form of NAT. Yes, it
> is well known that NAT breaks most protocols.
Not NAT. Default deny firewalls. Look at the recommended firewall configs
from pretty much any security consultant/vendor and see what happens when you
try to turn on (say) SCTP.
>> 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.
> The app would never become popular because most people would be unable to use
> it.
Right. See 'default deny firewalls'.
>> 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.
I believe at least one resolver (BIND) will do this for you. It first tries
using an extension that allows for a 4096-byte buffer. If that fails, it tries
using the extension with a 512-byte buffer. If that fails, it turns off the
extension. In the latter 2 cases, if the response is larger than 512 bytes, DNS
will automatically fall back to TCP. Increases latency, but that's life on the
Real Internet(tm).
>> 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).
> Yes, this is an increasingly common problem. Thanks, Micr0$0ft.
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the
real IPng.
Regards,
-drc
