[146799] in North American Network Operators' Group
Re: Dynamic (changing) IPv6 prefix delegation
daemon@ATHENA.MIT.EDU (David Conrad)
Tue Nov 22 12:16:28 2011
From: David Conrad <drc@virtualized.org>
In-Reply-To: <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com>
Date: Tue, 22 Nov 2011 09:15:15 -0800
To: Owen DeLong <owen@delong.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.=20
Regards,
-drc
