[ipv6hackers] Dynamic prefixes & privacy (was: IPv6 prefix changing)
Alex List
I know that this discussion is not new [3], but to me the problem in
Germany seems to be more related to the fact that, without dynamic
prefixes, a residential customer would be obliged to use a sort of ID
he/she cannot change. Tracking is possible anyway. The problem is to
what extent one can influence that. In Germany there is (imho rather
utopic) the "law"/concept of informational self-determination [1]. A
fixed ID in the Internet can bring back the memories of [2], a very
sensitive topic, specially for older generations.
Regards, Alex
Refs:
[1] http://de.wikipedia.org/wiki/Informationelle_Selbstbestimmung
[2] http://en.wikipedia.org/wiki/Stasi
[3] "dynamic or static IPv6 prefixes to residential customers",
http://seclists.org/nanog/2011/Jul/440
2012/3/8 S.P.Zeidler <s...@serpens.de>
>
> Hi,
>
> Thus wrote Markus Reschke (mad...@theca-tabellaria.de):
>
> [...]
> > The only thing I can think of is that the office for data privacy
> > recommends dynamic addresses. Since static addresses can be tracked
> > easily, nobody should be forced by the ISP to use them. Therefore
> > the default should be dynamic addresses with the option to switch to
> > static ones if requested by the customer.
> [...]
>
> I think that an (implied) assumption that dynamic addresses protect
> against tracking is a dangerous fallacy. Starting to get off-topic though.
>
> regards,
> spz
> --
> s...@serpens.de (S.P.Zeidler)
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6h...@lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers
Owen DeLong
assigned to the end user. The upstream connection address is likely at least
persistent if not static over long enough intervals to be a traceable
identifier that the end user cannot influence.
Rotating the customer prefix can only create an illusion of increased privacy
while not providing any actual increase in privacy. Allowing the user to choose
to provide such an illusion or not is, I suppose, a form of self-determination,
but, I'm not sure I understand the value.
Owen
The Fungi
[...]
> A fixed ID in the Internet can bring back the memories of [2], a
> very sensitive topic, specially for older generations.
Which is a disappointing leap of misunderstanding, given that a
fixed Internet address is more akin to a fixed postal/street
address. If your address always changed, the mail and the fire
brigade might have a lot more trouble locating your home. Hopefully
German law doesn't dictate that everyone should get a different
street address every day?
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
Eugen Leitl
> On 2012-03-12 07:15:02 +0000 (+0000), Alex List wrote:
> [...]
> > A fixed ID in the Internet can bring back the memories of [2], a
> > very sensitive topic, specially for older generations.
> [...]
>
> Which is a disappointing leap of misunderstanding, given that a
> fixed Internet address is more akin to a fixed postal/street
> address. If your address always changed, the mail and the fire
> brigade might have a lot more trouble locating your home. Hopefully
> German law doesn't dictate that everyone should get a different
> street address every day?
Instead of relying on anonymity by obscurity one should consider
using a dedicated anonymizing layer on static or dynamic addresses.
E.g. Tor https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#TorshouldsupportIPv6.
Tor should support IPv6.
That's a great idea! There are two aspects for IPv6 support that Tor needs. First, Tor needs to support exit to hosts that only have IPv6 addresses. Second, Tor needs to support Tor relays that only have IPv6 addresses.
The first is far easier: the protocol changes are relatively simple and isolated. It would be like another kind of exit policy.
The second is a little harder: right now, we assume that (mostly) every Tor relay can connect to every other. This has problems of its own, and adding IPv6-address-only relays adds problems too: it means that only relays with IPv6 abilities can connect to IPv6-address-only relays. This makes it possible for the attacker to make some inferences about client paths that it would not be able to make otherwise.
There is an IPv6 exit proposal to address the first step for anonymous access to IPv6 resources on the Internet.
Full IPv6 support is definitely on our "someday" list; it will come along faster if somebody who wants it does some of the work.
S.P.Zeidler
> he/she cannot change. Tracking is possible anyway. The problem is to
> what extent one can influence that. In Germany there is (imho rather
> utopic) the "law"/concept of informational self-determination [1]. A
There is also a law that requires that Internet services be useable
anonymously and pseudonymously. Of course there is another law that
requires that authors of content identify themselves. This Is Fun when
running even just a comments section to a blog. Actual legal practise
differs a lot depending on in which state you are (and how clueless
regarding Internet the judge is).
> fixed ID in the Internet can bring back the memories of [2], a very
> sensitive topic, specially for older generations.
So instead of playing security theater that does nothing but make the
clueless feel better (without affording them a iota more anonymity),
politics could mandante anonymizing proxies at providers that also filter
out common de-anonymizers. But that might make the advertising industry
complain, and noone wants that, right?
Markus Reschke
Hi!
> The fixed identifier for [2] is present regardless of the nature of the prefix
> assigned to the end user. The upstream connection address is likely at least
> persistent if not static over long enough intervals to be a traceable
> identifier that the end user cannot influence.
In the common design all DSL customers in an area are connected to a
single regional access router. For simple routing that access router has
fixed subnets for the customers (IP addresses are assigned dynamically out
of those subnets). That way you can learn which subnets belong to which
geographic area. If, in case of IPv6, a subnet is assigned to the
customer, and if you take the MAC-based automatic interface addresses into
account, you'll get a very nice solution to track users just by
the "not so dynamic" IP address. Fortunately the office for data privacy
knows about privacy extensions. They're not completely clueless :-)
> Rotating the customer prefix can only create an illusion of increased privacy
> while not providing any actual increase in privacy. Allowing the user to choose
> to provide such an illusion or not is, I suppose, a form of self-determination,
> but, I'm not sure I understand the value.
Yep! The big problem is misunderstanding. Even in this mailing list one
can read weird comments regarding the current thread about the German data
privacy law. Politicians don't understand technology, people too but
they trust media, most media is absolutely clueless and IT experts talk
IT-glibberish others don't understand. We say that x is a security
nightmare, officials try to enforce some kind of mitigation and the user
thinks everything's fine. Nice, isn't it?
Regards
Markus
--
/ Markus Reschke \ / mad...@theca-tabellaria.de \ / FidoNet 2:244/1661 \
\ / \ / \ /
Owen DeLong
On Mar 12, 2012, at 8:09 AM, Markus Reschke wrote:
> On Mon, 12 Mar 2012, Owen DeLong wrote:
>
> Hi!
>
>> The fixed identifier for [2] is present regardless of the nature of the prefix
>> assigned to the end user. The upstream connection address is likely at least
>> persistent if not static over long enough intervals to be a traceable
>> identifier that the end user cannot influence.
>
> In the common design all DSL customers in an area are connected to a single regional access router. For simple routing that access router has
> fixed subnets for the customers (IP addresses are assigned dynamically out of those subnets). That way you can learn which subnets belong to which geographic area. If, in case of IPv6, a subnet is assigned to the customer, and if you take the MAC-based automatic interface addresses into account, you'll get a very nice solution to track users just by the "not so dynamic" IP address. Fortunately the office for data privacy knows about privacy extensions. They're not completely clueless :-)
>
Yes, the addresses within that subnet for a geographic area are technically dynamic. However, reality is that they are actually persistent over long enough periods of time as to be effectively static for tracking purposes.
Privacy extensions only modify the suffix. They do nothing to anonymize the prefix. and they don't meaningfully apply to the provider-facing address on the home gateway (the CPE router which connects to the provider's network).
>> Rotating the customer prefix can only create an illusion of increased privacy
>> while not providing any actual increase in privacy. Allowing the user to choose
>> to provide such an illusion or not is, I suppose, a form of self-determination,
>> but, I'm not sure I understand the value.
>
> Yep! The big problem is misunderstanding. Even in this mailing list one can read weird comments regarding the current thread about the German data privacy law. Politicians don't understand technology, people too but they trust media, most media is absolutely clueless and IT experts talk IT-glibberish others don't understand. We say that x is a security nightmare, officials try to enforce some kind of mitigation and the user thinks everything's fine. Nice, isn't it?
>
Not so much, no.
Owen
Alex List
eyeball isp. If you manage your network of course you can track your
user. But let's think about third-party internet marketing companies.
Wouldn't it be much easier to them to correlate data if residential
customers were forced to have the same IP all the time?
I find that browsers today are still quite dumb in terms of privacy
[1], but I hope that more and more people will care about it [2][3]. A
long term static IP addresses would make the use of proxies a must.
Maybe the problem of such discussions is that we tend to think that
one option would exclude the other. I'd rather have multi-prefix
networks with more intelligent applications that understand what to do
when connected to various networks simultaneously. This seems to be an
extremely hard task though.
Refs:
[1] http://collusion.toolness.org/
[2] https://addons.mozilla.org/en-US/firefox/addon/betterprivacy/
[3] http://donottrack.us/
2012/3/12 Owen DeLong <ow...@he.net>:
Alex List
difficult to find good analogies. At first glance yours seems good,
but even the layman would then ask what happens with Internet on the
smart phones and it's perfectly possible to have static addresses
while mobile. An another analogy would be as if we were demanded to
carry our personal ID card visible wherever we go.
2012/3/12 The Fungi <fu...@yuggoth.org>:
Markus Reschke
Hi!
If I mis-understood you please tell me.
> I think you are both reasoning too much from the perspective of an
> eyeball isp. If you manage your network of course you can track your
> user. But let's think about third-party internet marketing companies.
> Wouldn't it be much easier to them to correlate data if residential
> customers were forced to have the same IP all the time?
Yes and no :-) ISPs got the RADIUS logs. If users got fixed IP addresses
it's very easy to track them for third parties. If users got dynamic IPv6
subnets it's not much harder to track them by their IP address. The
third party just needs to do some mapping of networks, ISPs and locations.
Might be even a service of another company. There is a lot of geolocation
data in the Internet freely available. Add the automatic interface address
and you can identify the user. You're even able to see if the user
switches the ISP or moves to another area (if it's away far enough -
access-router-wise). For dynamic IPv4 addresses it's not that simple. The
marketing company needs to add some of the common webbrowser-based
methods.
Another problem with dynamic addresses is that a user might keep the
same address for a longer period of time. Some ISPs enforce a reset of the
Internet connection every x hours and assign a different IP address. Helps
a little with privacy. AS3320 does that every 24 hours for example.
Best recommendation for IPv6 to mitigate IP-based tracking, as described
above, is to use dynamic subnets and IPv6 privacy extensions. Or the DSL
router could perform some kind of address randomizing (for the interface part).
Otherwise it wouldn't matter much for user tracking if IPv6 subnets are
fixed or dynamic.
> I find that browsers today are still quite dumb in terms of privacy
> [1], but I hope that more and more people will care about it [2][3]. A
In the case of dynamic IPv6 subnets any privacy features would only
mitigate browser-based tracking, but IPv6 provides enough entropy to track
users without considering any super cookies, browser and plugin details
or whatever.
> long term static IP addresses would make the use of proxies a must.
> Maybe the problem of such discussions is that we tend to think that
> one option would exclude the other. I'd rather have multi-prefix
> networks with more intelligent applications that understand what to do
> when connected to various networks simultaneously. This seems to be an
> extremely hard task though.
You're right! There's no simple black-or-white situation. But we
should consider the average user Joe with his DSL connection most. He
doesn't know of IPv6 privacy extensions. So maybe the DSL router should do
the job.
Regards
Markus
--
/ Markus Reschke \ / mad...@theca-tabellaria.de \ / FidoNet 2:244/1661 \
\ / \ / \ /
Owen DeLong
Cookies, hidden gifs, and many other tools make tracking pretty easy
without needing access to the IP address stuff.
Further, even if you look at the rotating prefix implementations, the exterior
address of the home gateway tends to be static enough for tracking purposes
that it probably doesn't matter from a marketing perspective.
Owen
Tim Chown
Or can both be met?
Tim
Hannes Frederic Sowa
> Not really, no.
>
> Cookies, hidden gifs, and many other tools make tracking pretty easy
> without needing access to the IP address stuff.
Isn't tracking by ip or by cookie very orthogonal from a technical
standpoint? The outcome is the same, though. But that doesn't give IPv6
a free ticket to ignore all problems that protocols on higher levels
already introduced. That does violate the substitution principle.
> Further, even if you look at the rotating prefix implementations, the exterior
> address of the home gateway tends to be static enough for tracking purposes
> that it probably doesn't matter from a marketing perspective.
Jep.
--
Hannes Sowa <hs...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Alex List
> If I mis-understood you please tell me.
Probably I did
> Yes and no :-) ISPs got the RADIUS logs. If users got fixed IP addresses
> it's very easy to track them for third parties. If users got dynamic IPv6
> subnets it's not much harder to track them by their IP address. The third
> party just needs to do some mapping of networks, ISPs and locations. Might
> be even a service of another company. There is a lot of geolocation data in
> the Internet freely available. Add the automatic interface address and you
> can identify the user. You're even able to see if the user switches the ISP
> or moves to another area (if it's away far enough - access-router-wise). For
> dynamic IPv4 addresses it's not that simple. The marketing company needs to
> add some of the common webbrowser-based methods.
Do you mean that if prefixes were at least as random as IPv4 addresses
and privacy extensions were in place, then marketing companies would
need to rely on webbrowser-based methods?
Alex List
> Cookies, hidden gifs, and many other tools make tracking pretty easy
> without needing access to the IP address stuff.
But that shouldn't be an excuse for letting the IP layer jeopardize
privacy efforts[1][2] at the application layer.
> Further, even if you look at the rotating prefix implementations, the exterior
> address of the home gateway tends to be static enough for tracking purposes
> that it probably doesn't matter from a marketing perspective.
I don't like the term "rotating prefix". It blocks the vision of
having totally random prefixes. But that would currently be a
nightmare for network operators, wouldn't it?
> Further, even if you look at the rotating prefix implementations, the exterior
> address of the home gateway tends to be static enough for tracking purposes
> that it probably doesn't matter from a marketing perspective.
So if it tends to be static (I would rather say deterministic) how to
make it really random and what would be the implications of that?
Refs:
[1] https://addons.mozilla.org/en-US/firefox/addon/betterprivacy/
[2] http://donottrack.us/
2012/3/13 Owen DeLong <ow...@he.net>:
Markus Reschke
Hello Alex!
> Do you mean that if prefixes were at least as random as IPv4 addresses
> and privacy extensions were in place, then marketing companies would
> need to rely on webbrowser-based methods?
Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
make IP based tracking a lot harder and too inaccurate for the marketing
company.
There's only a very low randomness of IPv6 prefixes and IPv4
addresses in the real world. Each access router has some IPv4 subnets
and some larger IPv6 subnets assigned too. Out of those prefixes each
customer gets an IPv4 address and/or an IPv6 prefix. The goal is to have
as less routing entries as possible in your network. If an ISP would
assign IP addresses/prefixes randomly across the whole network there would
be a lot of trouble with the converging of dynamic routes. The randomness
is limited to the size of the fixed prefixes of the access router.
What does that mean for our marketing company? With some geo-location
(also whois and DNS reverse mapping) it can find out which prefixes of a
specific ISP are used in an area. The customers of that ISP in that area
will always have an address/prefix inside the same prefixes. oops :-)
Regards
Markus
--
/ Markus Reschke \ / mad...@theca-tabellaria.de \ / FidoNet 2:244/1661 \
\ / \ / \ /
Owen DeLong
On Mar 14, 2012, at 11:41 PM, Alex List wrote:
> Hi,
>
>> Cookies, hidden gifs, and many other tools make tracking pretty easy
>> without needing access to the IP address stuff.
>
> But that shouldn't be an excuse for letting the IP layer jeopardize
> privacy efforts[1][2] at the application layer.
>
I don't now. Should your area code and prefix be prevented from jeopardizing
your efforts to anonymize your location by turning off the GPS in your phone?
>> Further, even if you look at the rotating prefix implementations, the exterior
>> address of the home gateway tends to be static enough for tracking purposes
>> that it probably doesn't matter from a marketing perspective.
>
> I don't like the term "rotating prefix". It blocks the vision of
> having totally random prefixes. But that would currently be a
> nightmare for network operators, wouldn't it?
>
Yeah, that's utterly infeasible in anything resembling the current topologies and
technologies.
>> Further, even if you look at the rotating prefix implementations, the exterior
>> address of the home gateway tends to be static enough for tracking purposes
>> that it probably doesn't matter from a marketing perspective.
>
> So if it tends to be static (I would rather say deterministic) how to
> make it really random and what would be the implications of that?
>
Uh, I have no idea how to answer the first question. The implications of
attempting to do so would be a complete rewrite of the protocol and the
routing infrastructure from the ground up in order to facilitate such a
behavior. What you are asking for now is roughly on par with asking
to be assigned a random country code, city code, and phone number
for each call you make.
When you find a telco willing to do that, be sure to let me know, m'kay?
Owen
Alex List
> Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
> make IP based tracking a lot harder and too inaccurate for the marketing
> company.
Due to the /64 bits left I don't agree, but from the discussion so far
I understand that:
- there is indeed no point in using dynamic prefixes for privacy if
they were deterministic
- random prefix assignments scary many people
But wait, aren't ULA prefixes random? If CGNs were here to stay[1],
why couldn't they provide a "network layer privacy" [2] service? If
they claim to be so good at NATPT44, NPTv6 should be a piece of cake.
Alex
Refs:
[1] "shared address space... a reality!",
http://mailman.nanog.org/pipermail/nanog/2012-March/thread.html#46691
[2] @Tim: thanks for this term.
Alex List
code, city code, and phone number when I'm on the beach and I need to
call my boss. Of course, I would turn off the GPS just to be sure.
Or I can call my colleague to call my boss and hope that she'll not
tell him me where I am. :-)
Owen DeLong
On Mar 16, 2012, at 1:06 AM, Alex List wrote:
> Hi,
>
>> Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
>> make IP based tracking a lot harder and too inaccurate for the marketing
>> company.
>
> Due to the /64 bits left I don't agree, but from the discussion so far
> I understand that:
>
> - there is indeed no point in using dynamic prefixes for privacy if
> they were deterministic
> - random prefix assignments scary many people
>
> But wait, aren't ULA prefixes random? If CGNs were here to stay[1],
> why couldn't they provide a "network layer privacy" [2] service? If
> they claim to be so good at NATPT44, NPTv6 should be a piece of cake.
>
ULA prefixes can't talk to the global internet. If you don't want to talk to
the global internet and have packets routed back to you, you can be as
anonymous as you want. If you want the rest of the world to be able to
answer when you send them a packet, then there has to be a way for
them to get the answers back to you. Kind of reduces the probability
of useful anonymity short of using an anonymizing proxy or some other
such construct.
Perhaps you should become familiar with the basics of how routing
actually works before pursuing this further.
I wouldn't say that random prefix assignments scare people so much
as those of us who understand how the internet actually works realize
that they aren't really technically viable. (see my reference to having
your phone number randomized).
The difference is that in the phone network, since it is circuit switched,
the routing is all handled as part of the call setup and there is no need
for the remote destination to know the source address because the
destination does not participate at all in the routing decision.
With a packet switched network where each packet of information is
individually routed on a hop-by-hop basis, the story is a bit different.
The remote destination has to be able to place the originators source
address into reply packet headers in order for them to reach the
originator.
IPv6 privacy extensions prevent one from using someone's MAC
address to track their mobility across different network segments.
They do nothing to anonymize your prefix.
Dynamic prefixes aren't exactly deterministic, but, they are what I would
call long-lived. In most cases to be useful in the routing system, they
need to be sufficiently long-lived that they can't really offer much in
the way of anonymitiy.
As to your question of "if CGNs are here to stay", well, hopefully they
are very much not here to stay. CGNs are a really bad hack. A worse
hack even than existing IPv4 NAT. They severely limit the utility of
the internet and the applications and innovations that can be
accomplished while they are in place. Hopefully they will be very
temporary in nature and will only apply to IPv4.
One of the biggest benefits of IPv6 is eliminating NAT. Adding it back
in is so antithetical to goodness I can only stare at your last sentence
in dismay and shake my head in disgust.
Owen
Owen DeLong
In a packet switched world, calling your colleague is available in the form of a variety of anonymizing proxy services.
Not disclosing your country code, city code, and phone number isn't really an option because there would be no way for you to hear your boss and the conversation would be decidedly one-sided.
Of course, that's metaphorical. At the packet level, your own packets wouldn't meaningfully get through because you'd never receive an ACK from the remote.
It is the inherent nature of the way packet switched networks work that you must disclose your origin address to the destination in order for communication to work.
NAT allows some obfuscation in this area, but, at the cost of breaking much of the desirable inherent nature of the internet in the process.
Owen
Markus Reschke
Hi Alex!
>> Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
>> make IP based tracking a lot harder and too inaccurate for the marketing
>> company.
> Due to the /64 bits left I don't agree, but from the discussion so far
For dynamic prefixes:
The 64 bits of the interface address is "randomized" by privacy extensions
and the other 64 bits tell us your ISP and your area. That's not much
data. The marketing company needs additional sources to be able to track
you.
For fixed IPv6 prefixes:
You would get a nice whois entry in the RIPE database :-) I haven't
checked it yet for IPv6, but there's some lower limit you don't need to
add the assignment. Any specific number known?
> I understand that:
>
> - there is indeed no point in using dynamic prefixes for privacy if
> they were deterministic
> - random prefix assignments scary many people
Maybe, but it's technically not feasable to randomize prefixes for a whole
ISP network. It would kill the IGP. You could do it for a small user base.
Each user would cause a dynamic route. At some point the amount of
dynamic routes is too large to handle and the routing will brake down.
> But wait, aren't ULA prefixes random? If CGNs were here to stay[1],
> why couldn't they provide a "network layer privacy" [2] service? If
> they claim to be so good at NATPT44, NPTv6 should be a piece of cake.
Just half of them :-) But CGN wouldn't help. Since the access routers
would perform CGN we have the same prefixes. So we know your ISP and area
again.
Regards,
Markus
--
/ Markus Reschke \ / mad...@theca-tabellaria.de \ / FidoNet 2:244/1661 \
\ / \ / \ /
Owen DeLong
On Mar 16, 2012, at 4:48 AM, Markus Reschke wrote:
> On Fri, 16 Mar 2012, Alex List wrote:
>
> Hi Alex!
>
>>> Not exactly, but yes. IPv6 privacy extensions alone would be sufficient to
>>> make IP based tracking a lot harder and too inaccurate for the marketing
>>> company.
>
>> Due to the /64 bits left I don't agree, but from the discussion so far
>
> For dynamic prefixes:
> The 64 bits of the interface address is "randomized" by privacy extensions and the other 64 bits tell us your ISP and your area. That's not much data. The marketing company needs additional sources to be able to track you.
>
Not really true.
The other 64 bits tell the careful observer quite a bit more...
The first 32 (or less) bits tell us your ISP.
The next 16 bits should narrow it down to an end-site in most cases (yes, some ISPs will do stupid things and give less than /48 to some customers unfortunately, at least initially). Admittedly, which end-site will change every once in a while, but, it will be stable enough in almost every case to be usable for limited marketing purposes, especially when correlated through other means such as cookies.
It's not perfect, but, ti's definitely good enough to be useful to the marketing companies. They don't seem to have too much trouble obtaining additional sources and they're getting better and better ad putting the pieces together even in realtime.
> For fixed IPv6 prefixes:
> You would get a nice whois entry in the RIPE database :-) I haven't checked it yet for IPv6, but there's some lower limit you don't need to add the assignment. Any specific number known?
>
Only if you are in Europe. Outside of Europe, likely your nice entry would be in some other RIRs database or in some ISPs RWHOIS server.
As to the lower limit, I believe it varies by region. In the ARIN region, I think it is /64.
>> But wait, aren't ULA prefixes random? If CGNs were here to stay[1],
>> why couldn't they provide a "network layer privacy" [2] service? If
>> they claim to be so good at NATPT44, NPTv6 should be a piece of cake.
>
> Just half of them :-) But CGN wouldn't help. Since the access routers would perform CGN we have the same prefixes. So we know your ISP and area again.
>
Actually, all currently defined ULA prefixes are supposed to be random. There is a reservation for future RFC work on ULA-registered, but, I believe that all of the drafts languished into expiration and it never came to fruition. Personally, I think that's a good thing. I would like to deprecate ULA altogether as an unnecessary and poorly conceived waste of address space. (Not that I'm concerned about the use of the space nearly so much as the possibility that someone might actually deploy ULA in a myriad of harmful ways and that there aren't actually any good use cases for it that I have seen as yet).
Owen
Gert Doering
On Fri, Mar 16, 2012 at 12:48:42PM +0100, Markus Reschke wrote:
> Maybe, but it's technically not feasable to randomize prefixes for a whole
> ISP network. It would kill the IGP. You could do it for a small user base.
> Each user would cause a dynamic route. At some point the amount of
> dynamic routes is too large to handle and the routing will brake down.
You don't really need to fully randomize that. Just knowing that the
prefix is not attached to a fixed user will de-value its usefulness
as a tracking help enormously.
Yes, it will tell someone "which country, which ISP, which region", but
not specifically "this household" (prefixes never identify "this user",
at most "this machine" or "this network behind a single CPE").
No point in making a big fuzz about it - if end users think they need that,
well, "just giving out prefixes from a pool" is much easier to provision
than "make sure it's always the same prefix, even if you have to restructure
your network, split a full DSLAM into two, etc., and all of a sudden you
can't aggregate the pool anymore"...
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Karl Auer
On Fri, 2012-03-16 at 09:06 +0100, Alex List wrote:
> Due to the /64 bits left I don't agree, but from the discussion so far
With IPv4, the outside address on the CPE effectively identifies at
least the household. For a household containing one computer, it
identifies that computer, NAT or no NAT. That outside address may
change, but it changes fairly slowly unless ISPs make a special effort
to either keep it stable or change it frequently.
With IPv6, the prefix will identify the household with roughly the same
effectiveness. And possibly the outside address will too, though that
will typically be an invisible routing hop rather than an apparent
connection endpoint, as it is with IPv4 and NAT.
As long as privacy addresses are used, IPv6 doesn't make that any worse.
It could be argued that it makes things slightly better, as "outsiders"
can no longer see (at least not just from the address) whether
connections are from the same actual computer or not.
Without privacy addresses IPv6 makes it worse in direct proportion to
the number of computers using the prefix. And a LOT worse for mobile
computers, which can now be fairly positively identified wherever they
go, using the rightmost 64 bits.
DHCPv6-supplied addresses fall somewhere between the two. They will have
the same address on any given network, but different addresses on
different networks. So same difficulty for sessile computers, slightly
better for mobile computers.
Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
S.P.Zeidler
> You're right! There's no simple black-or-white situation. But we
> should consider the average user Joe with his DSL connection most.
> He doesn't know of IPv6 privacy extensions. So maybe the DSL router
> should do the job.
By no means. Their OS will likely be Windows, and that will do privacy
addresses with great enthusiasm.
Users of other OSes will hopefully either have similar defaults or the
marginal clue needed to switch it on when/where wanted.
Breaking end-to-end always comes at a price. Never do it just because you can.
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
S.P.Zeidler
> I would like to deprecate ULA altogether as an unnecessary and poorly conceived waste of address space. (Not that I'm concerned about the use of the space nearly so much as the possibility that someone might actually deploy ULA in a myriad of harmful ways and that there aren't actually any good use cases for it that I have seen as yet).
Use in walled gardens that majorly won't connect to the Internet but are
comprised of multiple entities, f.e. Both the 'not generally routable'
and 'not accidentially conflicting' are security features (or sanity
features, since it's more a question of not spilling than of not getting
intentionally attacked).
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
S.P.Zeidler
[...]
> Dynamic home prefixes mean flash renumbering of multi-subnet home networks.
They also mean you cannot have any connections survive longer term,
since every prefix change will kill them (unless you push them through the
moral equivalent of a tunnel that you restore as soon as you have the new
address).
They also mean that your connection is restricted to a role of consumer,
not a full participant of the Internet.
regards,
spz
Owen DeLong
On Mar 17, 2012, at 10:41 AM, S.P.Zeidler wrote:
> Thus wrote Markus Reschke (mad...@theca-tabellaria.de):
>
>> You're right! There's no simple black-or-white situation. But we
>> should consider the average user Joe with his DSL connection most.
>> He doesn't know of IPv6 privacy extensions. So maybe the DSL router
>> should do the job.
>
> By no means. Their OS will likely be Windows, and that will do privacy
> addresses with great enthusiasm.
>
> Users of other OSes will hopefully either have similar defaults or the
> marginal clue needed to switch it on when/where wanted.
>
> Breaking end-to-end always comes at a price. Never do it just because you can.
>
Having OS default be privacy addresses is certainly less damaging than
breaking end-to-end..
Personally, I think having the OS default be SLAAC and if you want privacy,
you have to turn it on is a fine mechanism. Users that care can educate
themselves. Users that don't care enough to educate themselves will fail
to assure their privacy in other ways anyway.
Owen
Owen DeLong
On Mar 17, 2012, at 11:08 AM, S.P.Zeidler wrote:
> Thus wrote Owen DeLong (ow...@he.net):
>
>> I would like to deprecate ULA altogether as an unnecessary and poorly conceived waste of address space. (Not that I'm concerned about the use of the space nearly so much as the possibility that someone might actually deploy ULA in a myriad of harmful ways and that there aren't actually any good use cases for it that I have seen as yet).
>
> Use in walled gardens that majorly won't connect to the Internet but are
> comprised of multiple entities, f.e. Both the 'not generally routable'
> and 'not accidentially conflicting' are security features (or sanity
> features, since it's more a question of not spilling than of not getting
> intentionally attacked).
>
We can agree to disagree. Separate GUA with appropriate lack of routing and filtration (packet and routes) is every bit as sane and effective, every bit as secure, and far more versatile.
ULA brings nothing meaningful to the table.
Owen
Alex List
first of all, thank you for your participation in this discussion, I
really appreciate it.
> ULA prefixes can't talk to the global internet.
I know, that's the reason why I've mentioned NPTv6 [1]
> Perhaps you should become familiar with the basics of how routing
> actually works before pursuing this further...
Your advice surprised me, but I know it's difficult to estimate how
much a newcomer understand. Well, I myself have difficulties in
figuring out whether I really understand specific topics, thus I'm
very thankful when people tell me when I don't. I made the analogy of
calling my boss in order to illustrate what I want to achieve in terms
of information hiding. I was not thinking about the underlying
switching technology. In fact, in circuit switching I would not have
needed to use the metaphor of calling my colleague, as it's also
possible to disable the caller id [2]. I have no doubt that such level
of information hiding is much harder to achieve in packet switching
networks, especially when we consider the myriad of tracking
techniques available at the application layer. That is the reason why
I have named this thread "Dynamic prefixes and privacy". You may of
course argue that it does not make sense to focus at the network
layer, but that would be another discussion.
> IPv6 privacy extensions prevent one from using someone's MAC
> address to track their mobility across different network segments.
> They do nothing to anonymize your prefix.
Yes, that's clear to me [3].
> Dynamic prefixes aren't exactly deterministic, but, they are what I would
> call long-lived. In most cases to be useful in the routing system, they
> need to be sufficiently long-lived that they can't really offer much in
> the way of anonymitiy.
Interesting point. In your opinion, in the case of DSL residential
customers, what would be the minimum prefix lease time in order to be
useful for the routing system?
> As to your question of "if CGNs are here to stay", well, hopefully they
> are very much not here to stay. CGNs are a really bad hack. A worse
> hack even than existing IPv4 NAT. They severely limit the utility of
> the internet and the applications and innovations that can be
> accomplished while they are in place. Hopefully they will be very
> temporary in nature and will only apply to IPv4.
Actually that was not a question, but rather a premise for the
subsequent statement. If I need a CGN in my infrastructure, and for
whatever reason a customer wants me to do NPTv6 on his behalf, I'd
like to understand whether it would make sense to use the CGN for
that.
> One of the biggest benefits of IPv6 is eliminating NAT. Adding it back
> in is so antithetical to goodness I can only stare at your last sentence
> in dismay and shake my head in disgust.
Sorry, I didn't expect that my last sentence would raise such
feelings. I'll try to be more careful with the language when dealing
with controversial topics next time.
Regards, Alex
Refs:
[1] "NPTv6: The Simplest Case", http://tools.ietf.org/html/rfc6296#section-2.1
[2] http://en.wikipedia.org/wiki/Caller_ID#Disabling
[3] "Privacy Extensions for Stateless Address Autoconfiguration in
IPv6", http://tools.ietf.org/html/rfc4941
Owen DeLong
On Mar 19, 2012, at 12:47 AM, Alex List wrote:
> Hello Owen,
>
> first of all, thank you for your participation in this discussion, I
> really appreciate it.
>
>> ULA prefixes can't talk to the global internet.
>
> I know, that's the reason why I've mentioned NPTv6 [1]
>
But even with NPTv6, you're translating to a (quasi)-fixed locator
in order to get the end result you desire (internet access). That
translated locator is trackable, so, you've eliminated the benefit
you are seeking from the NPT unless you can somehow randomize
the locator.
Problem is, randomizing the locator is sort of like trying to give someone
directions to your house when your street changes names and is renumbered
frequently. It just doesn't tend to work out well, which is why people
don't have rapidly changing phone numbers or rapidly changing
street addresses.
Think of going to a website as being akin to ordering a product from
Amazon. At some point, in order to be able to receive what you requested,
you have to share a certain amount of personal information (address
and payment information, for example) to facilitate the transaction.
So it is with being able to get a response from a web site, receive email,
etc. In order for the internet to deliver what you want, you have to
tell the internet who/where you are to at least some extent.
>> Perhaps you should become familiar with the basics of how routing
>> actually works before pursuing this further...
>
> Your advice surprised me, but I know it's difficult to estimate how
> much a newcomer understand. Well, I myself have difficulties in
> figuring out whether I really understand specific topics, thus I'm
> very thankful when people tell me when I don't. I made the analogy of
> calling my boss in order to illustrate what I want to achieve in terms
> of information hiding. I was not thinking about the underlying
> switching technology. In fact, in circuit switching I would not have
> needed to use the metaphor of calling my colleague, as it's also
> possible to disable the caller id [2]. I have no doubt that such level
> of information hiding is much harder to achieve in packet switching
> networks, especially when we consider the myriad of tracking
> techniques available at the application layer. That is the reason why
> I have named this thread "Dynamic prefixes and privacy". You may of
> course argue that it does not make sense to focus at the network
> layer, but that would be another discussion.
>
I do, in fact argue that trying to achieve privacy at the network level
is every bit as absurd on the internet as it would be in any other
analogous form of human interaction.
As to disabling caller id[2] that's actually a myth (sort of). While you
can disable caller id well enough to mask your identity to the casual
observer, it doesn't have that effect when you call any of the following:
1. An 800 number.
2. Any 911 dispatch center (whether you called 911, 311, or
any of a myriad of other numbers that end up there).
3. Any PSAP (Public Service Access Point)
4. Any entity that receives their phone calls on a digital trunk
5. Any entity other than a cell phone which may be billed per minute
for your call.
6. Several other categories of destination that I'm not able
to recall off the top of my head at the moment.
>
>> IPv6 privacy extensions prevent one from using someone's MAC
>> address to track their mobility across different network segments.
>> They do nothing to anonymize your prefix.
>
> Yes, that's clear to me [3].
>
>> Dynamic prefixes aren't exactly deterministic, but, they are what I would
>> call long-lived. In most cases to be useful in the routing system, they
>> need to be sufficiently long-lived that they can't really offer much in
>> the way of anonymitiy.
>
> Interesting point. In your opinion, in the case of DSL residential
> customers, what would be the minimum prefix lease time in order to be
> useful for the routing system?
>
Well, every time you change prefixes, you disrupt the user's flows. If that
happens more than once a week, you tend to get customer complaints
about it. You're also likely (though not necessarily) going to create
route flaps which may lead to BGP penalties and increased convergence
which can cause up to 15-30 minutes of disruption.
Bottom line, most providers strive to minimize these disruptions because
most customers don't like them. I don't know of too many people who
care enough about hiding from the marketing spooks to make them
worth the performance/stability penalty that they carry. I know that I
have had the same IP lease from Comcast, for example, in IPv4 for
almost 2 years at this point.
>> As to your question of "if CGNs are here to stay", well, hopefully they
>> are very much not here to stay. CGNs are a really bad hack. A worse
>> hack even than existing IPv4 NAT. They severely limit the utility of
>> the internet and the applications and innovations that can be
>> accomplished while they are in place. Hopefully they will be very
>> temporary in nature and will only apply to IPv4.
>
> Actually that was not a question, but rather a premise for the
> subsequent statement. If I need a CGN in my infrastructure, and for
> whatever reason a customer wants me to do NPTv6 on his behalf, I'd
> like to understand whether it would make sense to use the CGN for
> that.
>
Probably not. CGNs are targeted at IPv4 and for their hopefully limited
life span will probably need all the IPv4 performance they can muster.
Every provider will likely want to spend as little as possible on CGNs,
so will want to max out their IPv4 capabilities.
Further, I don't see how NPTv6 helps here. You still have to rotate the
external identifier and disrupt the users' sessions, so, I don't see any
benefit from NPT in the scenario.
>
>> One of the biggest benefits of IPv6 is eliminating NAT. Adding it back
>> in is so antithetical to goodness I can only stare at your last sentence
>> in dismay and shake my head in disgust.
>
> Sorry, I didn't expect that my last sentence would raise such
> feelings. I'll try to be more careful with the language when dealing
> with controversial topics next time.
>
Meh... it isn't the language. It's the concept.
NAT brings nothing but breakage to the IPv6 party.
Owen
S.P.Zeidler
> Well, every time you change prefixes, you disrupt the user's flows. If that
> happens more than once a week, you tend to get customer complaints
> about it.
Almost all German residential DSL plans reset their customers' connections
every 24h.
It used to be "to preserve IP addresses" (nobody believes that any more)
Now it's "but think of the chiiiildrun^W^Wprivacy"
Meanwhile, some people are so used to having manure heaped onto them that
they wonder how they will keep warm and moisturized if the daily helping
stops.
I don't have <de>Zwangstrennung</de>. I pay extra for this privilege.
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
Owen DeLong
On Mar 19, 2012, at 12:51 PM, S.P.Zeidler wrote:
> Thus wrote Owen DeLong (ow...@he.net):
>
>> Well, every time you change prefixes, you disrupt the user's flows. If that
>> happens more than once a week, you tend to get customer complaints
>> about it.
>
> Almost all German residential DSL plans reset their customers' connections
> every 24h.
> It used to be "to preserve IP addresses" (nobody believes that any more)
> Now it's "but think of the chiiiildrun^W^Wprivacy"
>
> Meanwhile, some people are so used to having manure heaped onto them that
> they wonder how they will keep warm and moisturized if the daily helping
> stops.
>
> I don't have <de>Zwangstrennung</de>. I pay extra for this privilege.
>
Well, very early in the thread, I had stated that I felt German privacy laws were
bizarre, dysfunctional, and somewhat insane in this regard. I now realize that
they aren't laws, but, some other form of {social,economic,governmental,other}
pressure that I don't fully understand, but which is somehow so pervasive that
it is often mistaken for law.
Regardless of the source, they have created a uniquely German brand of
dysfunction as near as I can tell. One which I would not want to inflict on
other parts of the world and one which I think Germany would be well served
to reconsider.
Owen
Marco Ermini
[...]
> Well, very early in the thread, I had stated that I felt German privacy laws were
> bizarre, dysfunctional, and somewhat insane in this regard. I now realize that
> they aren't laws, but, some other form of {social,economic,governmental,other}
> pressure that I don't fully understand, but which is somehow so pervasive that
> it is often mistaken for law.
>
> Regardless of the source, they have created a uniquely German brand of
> dysfunction as near as I can tell. One which I would not want to inflict on
> other parts of the world and one which I think Germany would be well served
> to reconsider.
Privacy laws in Germany are not that different from the rest of
Europe. There is, AFAIK, some addition in terms of capability of
monitoring workers. I work in a multi-national company (which is a
telco in Germany, BTW) and we need to have special rules in proxies
and similar, only for German employees.
However, it has to be said that these laws are the ones that permits
our data not to be sold to American companies which monetise from them
without any regards for the privacy of the people. In a certain sense
I am very glad that European data has to stay in Europe and that
something like what Google of Facebook do in the rest of the World, is
- in theory - monitored or at least contrasted in Europe (at least on
the paper).
That said,
1) I believe that's really out of topic here :-)
2) on my (German) cable connection, I very rarely get my IP address
changed (although it's only IPv4), and
3) I don't think there is any issue with either dynamic or static
addresses and/or prefixes for accounting, monitoring, etc. - every
tool we have today is able to check the user against a RADIUS system.
It is really much more like a monetisation issue - I can sell you
static addresses/prefixes for an additional price, as well as QoS
services, etc.
Cheers
--
Marco Ermini
root@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
Tim Chown
On 16 Mar 2012, at 13:54, Karl Auer wrote:
>
> DHCPv6-supplied addresses fall somewhere between the two. They will have
> the same address on any given network, but different addresses on
> different networks. So same difficulty for sessile computers, slightly
> better for mobile computers.
DHCPv6 supports issuing privacy/temporary addresses, I believe.
Thanks for the new word for my dictionary though :)
Tim
Tim Chown
On 17 Mar 2012, at 22:55, Owen DeLong wrote:
>
> ULA brings nothing meaningful to the table.
There is an I-D on ULA usage, see http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02. I would assume the authors would like feedback.
Having ULA-ULA communication in a homenet is a good thing if that means internal connections are not dropped if the accompanying global prefix changes.
In the homenet scenario, it seems some LLN vendors say they only want to use ULAs.
Tim
Owen DeLong
On Mar 20, 2012, at 2:34 PM, Tim Chown wrote:
>
> On 17 Mar 2012, at 22:55, Owen DeLong wrote:
>>
>> ULA brings nothing meaningful to the table.
>
> There is an I-D on ULA usage, see http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02. I would assume the authors would like feedback.
>
> Having ULA-ULA communication in a homenet is a good thing if that means internal connections are not dropped if the accompanying global prefix changes.
>
A better solution is to provide some internal persistence on global prefixes in the absence of external communication.
Yes, you'll still drop internal connections on a renumber event, but, that can be handled gracefully enough so as not to be of sufficient concern to merit the drawbacks of using ULA.
> In the homenet scenario, it seems some LLN vendors say they only want to use ULAs.
Herein lies the real hazard of ULA. Forcing NPT into the world is a really really really bad thing.
Owen
Douglas Otis
>
> On Mar 20, 2012, at 2:34 PM, Tim Chown wrote:
>
> On 17 Mar 2012, at 22:55, Owen DeLong wrote:
> >>
> >> ULA brings nothing meaningful to the table.
> >
> > There is an I-D on ULA usage, see
> > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02.
> > I would assume the authors would like feedback.
> >
> > Having ULA-ULA communication in a homenet is a good thing if that
> > means internal connections are not dropped if the accompanying
> > global prefix changes.
> >
> A better solution is to provide some internal persistence on global
> prefixes in the absence of external communication.
>
> Yes, you'll still drop internal connections on a renumber event, but,
> that can be handled gracefully enough so as not to be of sufficient
> concern to merit the drawbacks of using ULA.
>
> > In the homenet scenario, it seems some LLN vendors say they only
> > want to use ULAs.
>
> Herein lies the real hazard of ULA. Forcing NPT into the world is a
> really really really bad thing.
Dear Owen,
I agree with Tim. While NPTv6 should be avoided, there are situations
that arise when dealing with IPv4 NATs.
http://tools.ietf.org/html/rfc6281#page-11 also makes this point by
using ULAs leverage IPv6 as a method for ensuring unique local
identifiers able to retain security associations. In this case, the
identifier lifetime needs to exceed that of any TCP connection or
Security Association running on the host. The HIP alternative may not
be supported.
Regards,
Douglas Otis
Owen DeLong
On Mar 20, 2012, at 3:28 PM, Douglas Otis wrote:
> On 3/20/12 2:37 PM, Owen DeLong wrote:
>>
>> On Mar 20, 2012, at 2:34 PM, Tim Chown wrote:
>>
>> On 17 Mar 2012, at 22:55, Owen DeLong wrote:
>> >>
>> >> ULA brings nothing meaningful to the table.
>> >
>> > There is an I-D on ULA usage, see
>> > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02.
>> > I would assume the authors would like feedback.
>> >
>> > Having ULA-ULA communication in a homenet is a good thing if that
>> > means internal connections are not dropped if the accompanying
>> > global prefix changes.
>> >
>> A better solution is to provide some internal persistence on global
>> prefixes in the absence of external communication.
>>
>> Yes, you'll still drop internal connections on a renumber event, but,
>> that can be handled gracefully enough so as not to be of sufficient
>> concern to merit the drawbacks of using ULA.
>>
>> > In the homenet scenario, it seems some LLN vendors say they only
>> > want to use ULAs.
>>
>> Herein lies the real hazard of ULA. Forcing NPT into the world is a
>> really really really bad thing.
>
> Dear Owen,
>
> I agree with Tim. While NPTv6 should be avoided, there are situations that arise when dealing with IPv4 NATs. http://tools.ietf.org/html/rfc6281#page-11 also makes this point by using ULAs leverage IPv6 as a method for ensuring unique local identifiers able to retain security associations. In this case, the identifier lifetime needs to exceed that of any TCP connection or Security Association running on the host. The HIP alternative may not be supported.
>
Apple could easily have obtained an IPv6 GUA prefix for this purpose. The use of ULA is entirely optional.
Free your mind from the IPv4 private vs. public address mindset and allow yourself to consider a world where
GUA is relatively easy to obtain and can be used for non-connected purposes without penalty or difficulty.
I realize that this would require some RIR policy changes and I support those. If the IETF will get on board
with recognizing that local GUA is a better alternative than ULA, then I don't think it would be hard to get
the RIRs to adopt appropriate policy around this.
Owen
Douglas Otis
While agreeing with most of your statements, when GUAs are intended to
be local, as are ULAs, this makes their handling is more complex. With
the various IPv6 transitional methods kicking around, GUA packets might
end up in strange places and enable various data exfiltration
techniques, for example. In Apple's case, ULAs still seem like a better
and simpler choice.
Regards,
Douglas Otis
Alex List
> But even with NPTv6, you're translating to a (quasi)-fixed locator
> in order to get the end result you desire (internet access). That
> translated locator is trackable, so, you've eliminated the benefit
> you are seeking from the NPT unless you can somehow randomize
> the locator.
That's not a problem, my customers trust to me that I won't disclosure
their households. This is part of my service aggreement.
> Problem is, randomizing the locator is sort of like trying to give someone
> directions to your house when your street changes names and is renumbered
> frequently.
As Gert mentioned, you don't need to fully randomize that. It's enough
when people know how to find our building. We have a doorman who can
give visitors further directions.
> It just doesn't tend to work out well, which is why people
> don't have rapidly changing phone numbers or rapidly changing
> street addresses.
They do, as people have mobiles, but the underlying system take cares
of handoffs.
> Think of going to a website as being akin to ordering a product from
> Amazon. At some point, in order to be able to receive what you requested,
> you have to share a certain amount of personal information (address
> and payment information, for example) to facilitate the transaction.
Yes, I aggree, it's part of my service aggreement to do in that in
behalf of my customers.
> So it is with being able to get a response from a web site, receive email,
> etc. In order for the internet to deliver what you want, you have to
> tell the internet who/where you are to at least some extent.
Yes, I'm aware of the identication and location function of IP
addresses (and the current efforts for separating them for the
Inter-Domain Routing [7]). Because of my scope, I think it's perfectly
reasonable to randomize the prefix to a certain extent.
> I do, in fact argue that trying to achieve privacy at the network level
> is every bit as absurd on the internet as it would be in any other
> analogous form of human interaction.
Well, I disagree, because there are forms of human interaction that
requires a representative, e.g. mediation [1].
> As to disabling caller id[2] that's actually a myth (sort of). While you
> can disable caller id well enough to mask your identity to the casual
> observer, it doesn't have that effect when you call any of the following:
>
> 1. An 800 number.
> 2. Any 911 dispatch center (whether you called 911, 311, or
> any of a myriad of other numbers that end up there).
> 3. Any PSAP (Public Service Access Point)
> 4. Any entity that receives their phone calls on a digital trunk
> 5. Any entity other than a cell phone which may be billed per minute
> for your call.
> 6. Several other categories of destination that I'm not able
> to recall off the top of my head at the moment.
It's enough to mask the identity of my customers to the casual
observer. For the services like VoIP I can use other prefixes. I know
there might be issues with multihoming[4], btw, there's going to be an
interesting talk [3] in the next IPv6-Kongress[2].
> Well, every time you change prefixes, you disrupt the user's flows. If that
> happens more than once a week, you tend to get customer complaints
> about it.
That's no problem for services like web browsing, and I can always
equate that in my SLAs. For other services I can use other prefixes.
> You're also likely (though not necessarily) going to create
> route flaps which may lead to BGP penalties and increased convergence
> which can cause up to 15-30 minutes of disruption.
I don't need BGP.
> Bottom line, most providers strive to minimize these disruptions because
> most customers don't like them. I don't know of too many people who
> care enough about hiding from the marketing spooks to make them
> worth the performance/stability penalty that they carry. I know that I
> have had the same IP lease from Comcast, for example, in IPv4 for
> almost 2 years at this point.
>
I don't know in other countries, but I think there's a market for that
in Germany[5]. Btw, I'm expecting here a very extensive media coverage
of the World IPv6 Launch Day[6].
Regards, Alex
Refs:
[1] http://en.wikipedia.org/wiki/Mediation
[2] Der IPv6-Kongress 2012, http://www.ipv6-kongress.de/
[3] Multihoming für Client-Netze,
http://www.ix-konferenz.de/showabstract.php?vid=1869
[4] IPv6 Multihoming without Network Address Translation,
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04
[5] OpenWRT würfelt IPv6-Präfixe,
http://www.heise.de/netze/artikel/OpenWRT-wuerfelt-IPv6-Praefixe-1445607.html
[6] World IPv6 Launch Day, http://www.worldipv6day.org/
[7] Locator/ID Separation Protocol (LISP),
https://datatracker.ietf.org/doc/draft-ietf-lisp/
Markus Reschke
Hi!
>> Bottom line, most providers strive to minimize these disruptions because
>> most customers don't like them. I don't know of too many people who
>> care enough about hiding from the marketing spooks to make them
>> worth the performance/stability penalty that they carry. I know that I
>> have had the same IP lease from Comcast, for example, in IPv4 for
>> almost 2 years at this point.
>
> I don't know in other countries, but I think there's a market for that
> in Germany[5]. Btw, I'm expecting here a very extensive media coverage
> of the World IPv6 Launch Day[6].
The latest news from AS3320 regarding IPv6 prefixes:
They'll offer two privacy enhancements. A change-my-prefix-button at
the customer self-service homepage. And the other one is a prefix
randomizer built into their DSL routers. The router will choose a /64 out
of the assigned /56 and change the prefix from time to time.
IMHO those enhancements won't help anything, because we know the /56 as
soon as we see one of its /64s. The change-my-prefix-button is just a
manual version of dynamic prefixes. Without PE there's enough data
to track users by IPv6 addresses easily!
Regards,
Markus
--
/ Markus Reschke \ / mad...@theca-tabellaria.de \ / FidoNet 2:244/1661 \
\ / \ / \ /
S.P.Zeidler
[...]
> . Without PE there's enough
> data to track users by IPv6 addresses easily!
Please list all operating systems that do not do PE.
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
Owen DeLong
On Mar 21, 2012, at 7:21 AM, Markus Reschke wrote:
> On Wed, 21 Mar 2012, Alex List wrote:
>
> Hi!
>
>>> Bottom line, most providers strive to minimize these disruptions because
>>> most customers don't like them. I don't know of too many people who
>>> care enough about hiding from the marketing spooks to make them
>>> worth the performance/stability penalty that they carry. I know that I
>>> have had the same IP lease from Comcast, for example, in IPv4 for
>>> almost 2 years at this point.
>>
>> I don't know in other countries, but I think there's a market for that
>> in Germany[5]. Btw, I'm expecting here a very extensive media coverage
>> of the World IPv6 Launch Day[6].
>
> The latest news from AS3320 regarding IPv6 prefixes:
> They'll offer two privacy enhancements. A change-my-prefix-button at the customer self-service homepage. And the other one is a prefix randomizer built into their DSL routers. The router will choose a /64 out of the assigned /56 and change the prefix from time to time.
>
The change-my-prefix button seems like a reasonable approach to me. It allows those who want their prefix changed to have it done on demand while not inflicting it on the rest of the customer base. It's better than dynamic because it changes on demand, rather than being static for (possibly very long) periods of time.
The prefix randomizer is pretty silly.
> IMHO those enhancements won't help anything, because we know the /56 as soon as we see one of its /64s. The change-my-prefix-button is just a manual version of dynamic prefixes. Without PE there's enough data to track users by IPv6 addresses easily!
>
I'm not sure how PE helps to resolve this at the prefix level. Yes, it anonymizes the MAC address (and I can see some value in that for devices that move from network to network, though not enough to think it should be on by default), but, for a host that is on the same prefix consistently, I think PE is pretty irrelevant.
Owen
Hannes Frederic Sowa
> Thus wrote Markus Reschke (mad...@theca-tabellaria.de):
>
> [...]
>> . Without PE there's enough
>> data to track users by IPv6 addresses easily!
>
> Please list all operating systems that do not do PE.
AFAIK no Linux-Desktop does PE by default. NetworkManager added support
for PE just earlier this year. Defaults are still to off.
--
Hannes Sowa <hs...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
S.P.Zeidler
> I'm not sure how PE helps to resolve this at the prefix level.
It's not meant to. But if your goal is privacy, all change-my-prefix
actions are pointless is you are using a fixed, worldwide-unique local
part through all prefix changes.
For privacy at the address level, neither prefix changes alone
nor PE alone is sufficient, you must use both to get the same level
of mild obfuscation as you are getting from changing addresses
in IPv4 now.
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
Owen DeLong
Your IP public IP address is not obfuscated today and is akin to not changing (or at least not rapidly changing) prefixes in IPv6.
If you are counting on your public IPv4 address changing for privacy today, you are either suffering from a degraded network experience (most likely at the hands of a German ISP), or, you are deluding yourself.
Having a dynamic (though rarely changing) IPv6 prefix with PEA would provide roughly the same privacy as IPv4 today, which is nearly none.
Owen
Gert Doering
On Tue, Mar 20, 2012 at 03:52:20PM -0700, Owen DeLong wrote:
> Apple could easily have obtained an IPv6 GUA prefix for this purpose. The use of ULA is entirely optional.
>
> Free your mind from the IPv4 private vs. public address mindset and allow yourself to consider a world where
> GUA is relatively easy to obtain and can be used for non-connected purposes without penalty or difficulty.
"GUAs distributed with the intention of not having them routable world-wide"
is different from ULAs in exactly which way?
> I realize that this would require some RIR policy changes and I support those. If the IETF will get on board
> with recognizing that local GUA is a better alternative than ULA, then I don't think it would be hard to get
> the RIRs to adopt appropriate policy around this.
ULA-C would be that, but the IETF seems to have abandoned that idea.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering
On Wed, Mar 21, 2012 at 10:26:19AM -0700, Owen DeLong wrote:
> The prefix randomizer is pretty silly.
Amen.
("I know this is DTAG space, and they give a /56 to households, so why
should I even look at the next 8 bits?")
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Carlos Martinez-Cagnazzo
All this talk about depending on changing IPv4 assignments for privacy,
the 'NAT is security' mantra reminds me of Stockholm Syndrome. We've
been buried so long under these hacks that we accept them as if they
were good things.
Just as NAT is *not* a security tool, the periodic change of IPv4
assignments is *not a privacy tool*. This stupid hack started as an
artificial way of segmenting the broadband market into 'residential' and
'corporate' customers.
The idea (and I clearly remember vendor presentations expressing just
this and my clueless bosses at the time nodding with smiles in their
faces) was that in order to avoid cheap DSL carving into your profitable
Frame Relay/ATM services you had to somehow make it very hard for people
to host servers in their DSL services.
Fast forward 12 years, what we have now in my country is that FR/ATM
basically have ceased to exist and the low-end, SOHO market just hosts
their servers in the Amazon cloud or in just $2/mo El Cheapo hosting.
The hack accomplished nothing but giving us a harder-to-use network,
more failure-prone network.
</rant alert>
C.
Owen DeLong
On Mar 21, 2012, at 11:15 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 03:52:20PM -0700, Owen DeLong wrote:
>> Apple could easily have obtained an IPv6 GUA prefix for this purpose. The use of ULA is entirely optional.
>>
>> Free your mind from the IPv4 private vs. public address mindset and allow yourself to consider a world where
>> GUA is relatively easy to obtain and can be used for non-connected purposes without penalty or difficulty.
>
> "GUAs distributed with the intention of not having them routable world-wide"
> is different from ULAs in exactly which way?
>
Who said anything about intent on distribution. The intent on distribution is to uniquely number networks and hosts. Whether those networks and hosts are immediately connected, connected at some future time, or never connected becomes entirely the purview of the operator and irrelevant to the issuing agency.
That's the difference... GUAs provide maximum flexibility to the operator.
>> I realize that this would require some RIR policy changes and I support those. If the IETF will get on board
>> with recognizing that local GUA is a better alternative than ULA, then I don't think it would be hard to get
>> the RIRs to adopt appropriate policy around this.
>
> ULA-C would be that, but the IETF seems to have abandoned that idea.
>
Right... ULA-C wouldn't be that. ULA-C would be creating a new artificial PI that was not subject to RIR policies and guidelines and would, therefore have been a disaster. Abandoning it was a really good thing. ULA-R is bad enough.
Owen
S.P.Zeidler
> Not true.
Let me put this in context (you seem to be missing it).
Answering mail from a German, who had described the practise
of German Telekom (offering a "change my prefix button") and
saying that that wouldn't help privacy much without PE, you wrote:
> >> I'm not sure how PE helps to resolve this at the prefix level.
I answered:
> > [...] if your goal is privacy, all change-my-prefix
> > actions are pointless is you are using a fixed, worldwide-unique local
> > part through all prefix changes.
[...]
so yes, both the mail you replied to as well as my reply were about German
usage. Not "in all the world, you must now change your prefixes about as
often as your underwear for privacy reasons", but "if you are a German
user who is in love with having a non-stable IP address, mind to have PE
activated because a changing prefix alone will buy you exactly nothing".
Good?
Sure must be a culture shock to not have the implied environment be the US
but some other country for a change ;-P
S.P.Zeidler
> <rant alert>
> All this talk about depending on changing IPv4 assignments for privacy,
> the 'NAT is security' mantra reminds me of Stockholm Syndrome. We've
> been buried so long under these hacks that we accept them as if they
> were good things.
Exactly this. People are so used to "the network border is where the NAT
happens" that "there is no NAT" sends them into a panic.
Same with the Peanuts' Linus like love for the blanket of changing
IP address: doesn't actually help in the age of cookies, web bugs et al,
but makes the user feel better (and likely this false sense of security
makes them not use effective privacy measures, thus making it easier for
the people who want to track them to keep doing so).
Gert Doering
On Wed, Mar 21, 2012 at 12:48:30PM -0700, Owen DeLong wrote:
> > On Tue, Mar 20, 2012 at 03:52:20PM -0700, Owen DeLong wrote:
> >> Apple could easily have obtained an IPv6 GUA prefix for this purpose. The use of ULA is entirely optional.
> >>
> >> Free your mind from the IPv4 private vs. public address mindset and allow yourself to consider a world where
> >> GUA is relatively easy to obtain and can be used for non-connected purposes without penalty or difficulty.
> >
> > "GUAs distributed with the intention of not having them routable world-wide"
> > is different from ULAs in exactly which way?
>
> Who said anything about intent on distribution. The intent on distribution is to uniquely number networks and hosts. Whether those networks and hosts are immediately connected, connected at some future time, or never connected becomes entirely the purview of the operator and irrelevant to the issuing agency.
>
> That's the difference... GUAs provide maximum flexibility to the operator.
Unless you find a way to make "routing arbitrary prefixes assigned by
entity A via ISP B, C or D" *scale*, assigning GUAs outside of the
context of the operator who is supposed to route them not very much
different from an ULA - a block of 128 bit numbers, that needs a NPT
to be used on the Internet.
But this is becoming somewhat silly. I'm sure you know that, so I'm
wondering which aspect of "use GUAs assigned by some arbitrary entity"
I'm overlooking that might make it interesting.
> >> I realize that this would require some RIR policy changes and I support those. If the IETF will get on board
> >> with recognizing that local GUA is a better alternative than ULA, then I don't think it would be hard to get
> >> the RIRs to adopt appropriate policy around this.
> >
> > ULA-C would be that, but the IETF seems to have abandoned that idea.
>
> Right... ULA-C wouldn't be that. ULA-C would be creating a new artificial PI that was not subject to RIR policies and guidelines and would, therefore have been a disaster. Abandoning it was a really good thing. ULA-R is bad enough.
And how exactly is "changing the RIR policies to allow assignment of
local GUAs" different?
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Owen DeLong
On Mar 21, 2012, at 2:45 PM, Gert Doering wrote:
> Hi,
>
> On Wed, Mar 21, 2012 at 12:48:30PM -0700, Owen DeLong wrote:
>>> On Tue, Mar 20, 2012 at 03:52:20PM -0700, Owen DeLong wrote:
>>>> Apple could easily have obtained an IPv6 GUA prefix for this purpose. The use of ULA is entirely optional.
>>>>
>>>> Free your mind from the IPv4 private vs. public address mindset and allow yourself to consider a world where
>>>> GUA is relatively easy to obtain and can be used for non-connected purposes without penalty or difficulty.
>>>
>>> "GUAs distributed with the intention of not having them routable world-wide"
>>> is different from ULAs in exactly which way?
>>
>> Who said anything about intent on distribution. The intent on distribution is to uniquely number networks and hosts. Whether those networks and hosts are immediately connected, connected at some future time, or never connected becomes entirely the purview of the operator and irrelevant to the issuing agency.
>>
>> That's the difference... GUAs provide maximum flexibility to the operator.
>
> Unless you find a way to make "routing arbitrary prefixes assigned by
> entity A via ISP B, C or D" *scale*, assigning GUAs outside of the
> context of the operator who is supposed to route them not very much
> different from an ULA - a block of 128 bit numbers, that needs a NPT
> to be used on the Internet.
>
Scaling it becomes relatively trivial for N where N is < about 350,000 organizations (or about 10x the current number of BGP speaking ASNs) if (when) we can get rid of IPv4.
Further, we do eventually need to solve the prefix portability problem. It's kind of absurd that IETF chose not to drop the ball, but, to utterly ignore it and refuse to even pick it up and look at it during the design of IPv6.
> But this is becoming somewhat silly. I'm sure you know that, so I'm
> wondering which aspect of "use GUAs assigned by some arbitrary entity"
> I'm overlooking that might make it interesting.
>
I'm just pointing out that ULA doesn't provide any utility that GUA wouldn't while it comes at the price of not being able to subsequently use it for other purposes without renumbering if needs change.
Can you point to any functionality afforded by ULA that would preclude the use of GUA if GUA were readily available?
>
>>>> I realize that this would require some RIR policy changes and I support those. If the IETF will get on board
>>>> with recognizing that local GUA is a better alternative than ULA, then I don't think it would be hard to get
>>>> the RIRs to adopt appropriate policy around this.
>>>
>>> ULA-C would be that, but the IETF seems to have abandoned that idea.
>>
>> Right... ULA-C wouldn't be that. ULA-C would be creating a new artificial PI that was not subject to RIR policies and guidelines and would, therefore have been a disaster. Abandoning it was a really good thing. ULA-R is bad enough.
>
> And how exactly is "changing the RIR policies to allow assignment of
> local GUAs" different?
>
Because RIR policies at least provide for some mechanism for community input into the process if things start to get out of hand or if there are unforeseen problems developing with the allocation mechanism/policies having unintended consequences.
Owen
Fernando Gont
> I know that this discussion is not new [3], but to me the problem in
> Germany seems to be more related to the fact that, without dynamic
> prefixes, a residential customer would be obliged to use a sort of ID
> he/she cannot change. Tracking is possible anyway. The problem is to
> what extent one can influence that. In Germany there is (imho rather
> utopic) the "law"/concept of informational self-determination [1]. A
> fixed ID in the Internet can bring back the memories of [2], a very
> sensitive topic, specially for older generations.
I think one should draw a clear line between an address, and an identifier.
Addresses will always disclose your *position* in the network. They are
location-dependent identifiers (hence call "addresses").
Requiring providers to change the subnet bits for this purpose (which I
assume it is what is being discussed here, since you're talking about
"dynamic prefixes") is a bit nonsensical, since either:
a) Changing those bits does not help much in terms of privacy, or,
b) it requires your provider to actually (topologically) move your node, or
c) All of the above :-)
An entirely different question is that about how the Interface-ID is
selected. In that request, temporary addressses (RFC 4941) make sense,
and also the current MAC-derived addresses should also be replaced by
the scheme proposed in
<http://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-00.txt>.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492