From: Moe Trin on 3 Feb 2010 14:45 On Tue, 2 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in article <hk9ttn$urc$2(a)usenet01.boi.hp.com>, Rick Jones wrote: >It should be up to the client whether or not some portion of his IP >address is given up the chain, not a server. 1. This is a _draft_ of a proposed RFC - it's a work in progress, and must not be considered as anything solid. It's for hand-waving. 2. Have you read the draft? See section 8.1, specifically the second and third paragraphs. To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. No recommendation is provided for IPv6 at this time, but IPv6 addresses should be similarly truncated in order to not allow to uniquely identify the client. Users who wish their full IP address to be hidden can include an edns-client-ip option specifying the wildcard address 0.0.0.0/0 (i.e. FAMILY set to 1 (IPv4), NETMASK to 0 and no ADDRESS). As described in previous sections, this option will be forwarded across all the Recursive Resolvers supporting edns-client-ip, which MUST NOT modify it to include the network address of the client. Now, if your resolver or the immediate name server you are using doesn't include this option (or set things to the designated wild card), your address indications won't be included. I suspect the kernel authors will include a flag in /proc/net/some_where/or/another to control this. Old guy
From: Moe Trin on 3 Feb 2010 14:46 On Wed, 03 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in article <4b69548d$0$26305$8404b019(a)news.wineasy.se>, David Brown wrote: >Moe Trin wrote: >> It certainly is a benefit to the advertising service, and the >> company that is paying them to get the word of their products/ >> services to customers who may be interested. >That's correct. And while I have no more love for the advertising >industry than the average person, I have no objection to something >that helps them if it does no harm to anyone else. A lot of people don't understand a fundamental concept of the Internet. It's a shared mechanism - but it has costs, and those costs must be paid somehow. Using google as one example, _someone_ has got to be paying the electricity, water, telephone, and Internet connectivity bills, never mind paying for the hardware, building rent/mortgage, and the cost of the staff. Money does not come out of mid-air. Even the cost of the web-site run by your city library, or the pizza joint down the street has to come from somewhere - increased cost of a pizza or a lesser number of articles to lend out, somewhere! >The only disadvantage is perhaps that it will lower the cost of >advertising, and that might lead to more adverts. Probably. It certainly won't be spent improving the quality of the product, or the advertising. >> Even the authors admit it's going to increase the caching load on >> those DNS servers that may "support" clients in more than one >> geographical area - the "OpenDNS" being one example. Depending on >> what this service is actually used for, it can impact multi-national ]] networks. >I can see it being a particular issue for OpenDNS. Since google has >a rival system to OpenDNS, I suppose they are not going to be too >concerned about that... Hard to say - in the 'Attack scenarios' section of the 'Security Considerations' section, they seem to be aware of abuse/problems. >Surely in cases like this, you could simply continue to use your >existing DNS servers and caches - you would then see no difference >from the current situation. But if you decided to move to new DNS >software with support for client IP tracking (perhaps to improve >locality when accessing websites that run through big proxying >companies), you'd need to arrange for it to work in your wide network. o Recursive Resolvers implementing edns-client-ip should only enable it in deployments where it is expected to bring clear advantages to the end users. For example, when expecting clients from a variety of networks or from a wide geographical area. Due to the high cache pressure introduced by edns-client-ip, the feature must be disabled in all default configurations. I think one major unanswered question is what will the feature be used for _besides_ delivering advertisements. "Regional" updates of software doesn't sound likely - but what else is there? >I don't expect that this will be a quick change - even if it gains >popular support and the concept is refined so that "everyone" agrees >on it, [compton ~]$ zcat rfcs/rfc-index.01.15.10.txt.gz | sed 's/^$/\%/' | tr -d '\n' | tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed 's/.*Status: //' | tr -d '\)' | sort | uniq -c | column 172 BEST CURRENT PRACTICE 1732 INFORMATIONAL 141 DRAFT STANDARD 1974 PROPOSED STANDARD 321 EXPERIMENTAL 89 STANDARD 216 HISTORIC 909 UNKNOWN [compton ~]$ zgrep -c 'draft-' rfcs/drafts/1id-index.01.15.10.txt.gz 1680 [compton ~]$ A lot of drafts get proposed, discussed, modified, and so on, and some eventually get adopted while others silently time out and disappear. But I think I need to see more about this before I reach any decision. I especially want to see where this feature is going to be a benefit to _me_ (selfish, I know). Old guy
From: Rick Jones on 3 Feb 2010 16:24 If a portion of the end-client IP address is filtering past the first recursive server, isn't that giving somone watching the traffic that much more information about where people are going and what they are interested in? Not necessarily just advertisers. rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rick Jones on 3 Feb 2010 16:28 If it actually requires an active opt-in on the part of the end user before this functionality kicks-in, then my concern is addressed. rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Pascal Hambourg on 3 Feb 2010 18:13
Hello, Moe Trin a �crit : > > Now, if your resolver or the immediate name server you are using > doesn't include this option (or set things to the designated wild > card), your address indications won't be included. I suspect the > kernel authors will include a flag in /proc/net/some_where/or/another > to control this. Huh ? What does the kernel have to do with DNS ? |