[146787] in North American Network Operators' Group
Re: Dynamic (changing) IPv6 prefix delegation
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Nov 22 11:21:42 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net>
Date: Tue, 22 Nov 2011 08:19:25 -0800
To: Joel Maslak <jmaslak@antelope.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:
>=20
>> As long as a static allocation can be billed as a premium service,
>> most providers will unfortunately do it.
>=20
> Exactly. ISPs are in business to make as much money as they can - go =
figure.
>=20
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).
>=20
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:
>=20
> 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.
>=20
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).
>=20
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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
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.
>=20
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
