[143070] in North American Network Operators' Group
Re: dynamic or static IPv6 prefixes to residential customers
daemon@ATHENA.MIT.EDU (Sascha Lenz)
Wed Jul 27 09:14:58 2011
From: Sascha Lenz <slz@baycix.de>
In-Reply-To: <0904D2C5-0BBC-40B9-91BB-1677A95C3134@delong.com>
Date: Wed, 27 Jul 2011 15:14:37 +0200
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi Owen,
>>=20
>>> Hi all,
>>>=20
>>> I will like to know, from those deploying IPv6 services to =
residential
>>> customers, if you are planning to provide static or dynamic IPv6 =
prefixes.
>>>=20
>>> Just to be clear, I'm for static prefix delegation to residential
>>> customers, however I heard that some ISPs are doing dynamic =
delegations,
>>> the same way as is common today with IPv4.
>>>=20
>>> I don't thin it make sense, as the main reason for doing so in IPv4 =
was
>>> address exhaustion and legacy oversubscription models such as =
PPP/dial-up.
>>=20
>> well, it does make sense for most of the residential customers =
nowadays, because
>> they are indoctrinated with this idea of dynamic+NAT =3D=3D privacy =
for over a decade
>> now and don't know any better.
>>=20
> IMNSHO, education is always a better alternative than preserving =
ignorance or
> worse, mis-information.
>=20
I'm fully with you there, probably i should have elaborated a bit more.
In general, what Daniel said - at least in germany we have this problem =
that
static vs. dynamic Internet address assignments make a whole lot of a =
difference
in privacy when it comes to legal issues.
AND, even though we have next to no IPv6-deployment on a big scale here, =
there is
plenty of "education" going on in various media about how IPv6 will kill =
privacy
with "life-long IP addresses" and so on.
It's just not possible to counter that with technical arguments, at =
least not in the short-term.
I apologize for generalizing the situation in germany without =
explaining. I really hope
it's different in other markets and you are right.
But you will lose customers here if you don't offer some kind of dynamic =
prefixes, and=20
if you're dealing with the mass-market, you can't afford that.
Hence, my suggestion to just let your customers chose. Problem solved.
>=20
>> The best current practice would be, to default to a dynamic prefix, =
but enable your
>> more advanced customers to change that to a static prefix at will in =
your customer
>> service web-portal or something.
>>=20
>=20
> Sounds unnecessarily complicated and with absolutely no benefit =
whatsoever.
>=20
In this case, i beg to differ though.
It's not complicated but as easy as some change in your RADIUS database.
And, in contrast to things like NAT66, it doesn't break anything.
So, in my opinion, this is about giving the customers a choice, with no =
downsides.
It's somewhat similar to "privacy extensions - yes or no? default or =
not?" in the end.
One could discuss what the default should be, dynamic or static.
But just handing out static addresses even though it's relatively easy =
to give your
customers a choice, might be seen as "dictating" rather than =
"educating".
On a side-note: It's totally different with NAT of course, giving the =
people the choice=20
to use NAT will break things in the internet, again. I never would opt =
for that.
>> But i have no idea how to sell this to your marketing department.
>> They again are usually used to sell static IPs for an extra fee, and =
usually don't=20
>> want to change that with IPv6. That's bullshit for IPv6 of course.
>>=20
>=20
> It was mostly bullshit for IPv4.
>=20
Selling IPs? Indeed.=20
But there's nothing in any RIR policy to prevent that (anymore).
--=20
Mit freundlichen Gr=FC=DFen / Kind Regards
Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect
