[143079] in North American Network Operators' Group
Re: dynamic or static IPv6 prefixes to residential customers
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Jul 27 15:17:03 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <0E3C94C5-DB8A-4CEB-9769-613E8D61132B@baycix.de>
Date: Wed, 27 Jul 2011 12:11:39 -0700
To: Sascha Lenz <slz@baycix.de>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 27, 2011, at 6:14 AM, Sascha Lenz wrote:
> Hi Owen,
>=20
>>>=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
>=20
> I'm fully with you there, probably i should have elaborated a bit =
more.
>=20
> 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.
>=20
I don't doubt it=85 The German government has a long history of =
misunderstanding
privacy and what is required for real privacy.
> 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.
>=20
I think you are confusing "education" with mis-information. We have the =
same problem
with the media in the US. Especially Fox and other Rupert Murdoch =
organizations.
(Yes, I realize you quoted "education" to emphasize this, but, when we =
call it by their
terms, we propagate the myth that it is education.)
More effort is needed to re-educate the media and show them the true =
threats
to privacy. The reality is that a life-long prefix doesn't tell me =
anything more than
the neighborhood prefix will without other data. You aren't going to be =
able to get
around the neighborhood prefix issue no matter how often you renumber =
your
subscribers, and the other information will still provide the same =
correlations.
> It's just not possible to counter that with technical arguments, at =
least not in the short-term.
>=20
I disagree. It may not be possible to win the debate in the short term, =
but, that's
no excuse for failing to make the argument. We may be forced to do dumb =
things,
but, we can at least point out that they are dumb while we do them.
> I apologize for generalizing the situation in germany without =
explaining. I really hope
> it's different in other markets and you are right.
>=20
It is. In the US, the government is working hard to eliminate privacy =
anyway, so,
there is no such government opposition no matter how misinformed they =
are about
the issue. ;-)
> 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.
>=20
As I said, we may be forced to do dumb things, either by customer demand =
or by
government intervention. However, it never gets better if we fail to =
point out that
what we are doing is dumb along the way.
> Hence, my suggestion to just let your customers chose. Problem solved.
>=20
I have no problem with the solution, but, I have a serious problem with =
simply
rolling over with the solution and not making a technical argument as to =
why
it is both costly and counter-productive. Worst of all, your customers =
have this
false sense of security believing that their dynamic addresses actually =
provide
some measure of privacy.
>>=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
>=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.
>=20
It's not particularly complicated, but, it is unnecessarily complicated. =
It is more
complicated than straight static addressing and there is no need for it =
other
than FUD and misperception.
Yes, there are worse solutions available. Heart failure is worse than =
kidney
disease. I would prefer to avoid both.
> 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.
>=20
In my opinion, it is not without down-sides. It complicates several =
things, such
as troubleshooting, management, support systems, lawful intercept (ok, =
complicating
this may not be a bad thing), log and event correlation, trend analysis, =
etc.
It has additional costs that result from those complications.
> 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".
>=20
So far, none of our customers have objected, including thousands of =
tunnel broker
users in Germany.
> 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.
>=20
Glad to hear it. Yes, NAT is worse than what you propose and I don't =
really have
a problem with the solution where it is required for whatever =
(marketing, government,
FUD, or misperception) reason. However, I wouldn't tout it as the ideal =
case, but,
rather the necessary and minimal compromise to meet the unreasonable and
inaccurate expectations.
>>> 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
>=20
> Selling IPs? Indeed.=20
> But there's nothing in any RIR policy to prevent that (anymore).
>=20
Actually I don't believe LACNIC or AfriNIC have policies to allow that =
at this time.
Owen
