Re: Dynamic (changing) IPv6 prefix delegation

[Owen DeLong <owen () delong com>]

On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote:

> On Nov 22, 2011, at 8:05 AM, Ray Soucy <rps () 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.

How do you make more money by refusing to meet customer requests?

I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if 
you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry 
customers.

> 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 like being able to reach things in my house when I'm on the road. Having the prefix not bounce around turns out to be 
convenient for that.

> 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.

That's beyond tragic if it's actually true. You should name and shame your provider if that's really the case.

> 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).

I haven't run into too many of these in the real world any more other than actual tiered services where you have the 
option of buying a higher bandwidth service. What I mostly see these days is hard-limits on negotiated speed of the 
connection.

> 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.

> 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.

It wouldn't break the internet. The internet would break the app. in its current state.

Whether either of those possibilities is good or bad is left as an exercise for the reader.

> 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?).

Mostly it means that your provider sort of gets IPv6, but, not really. If you want to provide me with contact 
information off-list, I'll attempt to engage in an educational outreach.

> 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.

Yes, sounds like your provider needs to be hit with a clue-by-four. I don't think that typifies the rest of the world, 
though it's not as uncommon as I would like, either.

> 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.

> 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.

Huh? I haven't seen this problem at all. I've seen packets arrive with the ToS bits stripped, but, I haven't seen ToS 
cause a packet to get dropped. You seem to have found a particularly bleak set of providers to use.

> 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.

I expect my packets to get delivered (and they generally do) and I have static addresses too. You can have it all if 
you try.

Owen