<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.
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.
> 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
> On Mar 21, 2012, at 10:48 AM, S.P.Zeidler wrote:
>>> 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.
> 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.
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
Thus wrote Carlos Martinez-Cagnazzo (carlosm3...@gmail.com):
> <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).
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 _______________________________________________ Ipv6hackers mailing list Ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers
> 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.
> 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>.
