dynamic or static IPv6 prefixes to residential customers

Wed Jul 27 19:11:39 UTC 2011

On Jul 27, 2011, at 6:14 AM, Sascha Lenz wrote:

> Hi Owen,
> 
>>> 
>>>> Hi all,
>>>> 
>>>> I will like to know, from those deploying IPv6 services to residential
>>>> customers, if you are planning to provide static or dynamic IPv6 prefixes.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> well, it does make sense for most of the residential customers nowadays, because
>>> they are indoctrinated with this idea of dynamic+NAT == privacy for over a decade
>>> now and don't know any better.
>>> 
>> IMNSHO, education is always a better alternative than preserving ignorance or
>> worse, mis-information.
>> 
> 
> 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.
> 
I don't doubt it… 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.
> 

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

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

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 
> if you're dealing with the mass-market, you can't afford that.
> 

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

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.

>> 
>>> 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.
>>> 
>> 
>> Sounds unnecessarily complicated and with absolutely no benefit whatsoever.
>> 
> 
> 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.
> 

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

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

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 
> to use NAT will break things in the internet, again. I never would opt for that.
> 

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 
>>> want to change that with IPv6. That's bullshit for IPv6 of course.
>>> 
>> 
>> It was mostly bullshit for IPv4.
>> 
> 
> Selling IPs? Indeed. 
> But there's nothing in any RIR policy to prevent that (anymore).
> 

Actually I don't believe LACNIC or AfriNIC have policies to allow that at this time.

Owen