Dynamic (changing) IPv6 prefix delegation

David Conrad drc at virtualized.org
Tue Nov 22 17:15:15 UTC 2011


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





More information about the NANOG mailing list