From: "Krzysztof Olędzki" <ole@ans.pl>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Jan Engelhardt <jengelh@medozas.de>,
Ulrich Weber <ulrich.weber@sophos.com>,
Amos Jeffries <squid3@treenet.co.nz>,
"sclark46@earthlink.net" <sclark46@earthlink.net>,
"kaber@trash.net" <kaber@trash.net>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH 00/18] netfilter: IPv6 NAT
Date: Wed, 30 Nov 2011 01:30:54 +0100 [thread overview]
Message-ID: <4ED5793E.1090003@ans.pl> (raw)
In-Reply-To: <1322611509.2684.52.camel@bwh-desktop>
On 2011-11-30 01:05, Ben Hutchings wrote:
> On Tue, 2011-11-29 at 22:38 +0100, Krzysztof Olędzki wrote:
>> On 2011-11-29 13:23, Jan Engelhardt wrote:
>>>
>>> On Tuesday 2011-11-29 10:19, Ulrich Weber wrote:
>>>> On 28.11.2011 23:03, Amos Jeffries wrote:
>>>>> I'm going to dare to call FUD on those statements...
>>>>> * Load Balancing - what is preventing your routing rules or packet
>>>>> marking using the same criteria as the NAT changer? nothing. Load
>>>>> balancing works perfectly fine without NAT.
>>>
>>> Source address selection, having to occur on the source, would
>>> require that the source has to know all the parameters that a {what
>>> would have been your NAT GW} would need to know, which means you have
>>> to (a) collect and/or (b) distribute this information. Given two
>>> uplinks that only allow a certain source network address (different
>>> for each uplink), combined with the desire to balance on utilization,
>>> (a) a client is not in the position to easily obtain this data unless
>>> it is the router for all participants itself, (b) the clients needs
>>> to cooperate, and one cannot always trust client devices, or hope for
>>> their technical cooperation (firewalled themselves off).
>>>
>>> Yes, NAT is evil, but if you actually think about it, policies are
>>> best applied where [the policy] originates from. After all, we also
>>> don't do LSRR, instead, routers do the routing, because they just
>>> know much better.
>>>
>>>> I fully agree. NAT can not replace your firewall rules.
>>>>
>>>> However with NAT you could get some kind of anonymity.
>>>
>>> Same network prefix, some cookies, or a login form. Blam, identified,
>>> or at least (Almost-)Uniquely Identified Visitor tagging.
>>
>> But without NAT you have pretty big chance to have the same IPv6
>> *suffix* everywhere, based on you MAC address. In your Home, your Work,
>> in a Cafe or in a hotel during your vacations in Portugal. So yes, NAT
>> is not a perfect solution but it really helps you privacy.
>
> If you enable NAT on your own network, how does this help when you use
> all those other networks that may not use NAT or may have a predictable
> mapping from MAC address to public IPv6 address?
Oh, I understand your point. But I'm looking at it from the other side
as I'm here to protect my users. ;)
Best regards,
Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-30 0:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-24 16:57 [RFC PATCH 00/18] netfilter: IPv6 NAT kaber
2011-11-24 16:57 ` [PATCH 01/18] netfilter: nf_nat: export NAT definitions to userspace kaber
2011-11-24 16:57 ` [PATCH 02/18] netfilter: nf_nat: use hash random for bysource hash kaber
2011-11-24 16:57 ` [PATCH 03/18] netfilter: nf_nat: add missing nla_policy entry for CTA_NAT_PROTO attribute kaber
2011-11-24 16:57 ` [PATCH 04/18] netfilter: nat: remove module reference counting from NAT protocols kaber
2011-11-24 16:57 ` [PATCH 05/18] netfilter: nf_nat: remove obsolete code from nf_nat_icmp_reply_translation() kaber
2011-11-24 16:57 ` [PATCH 06/18] netfilter: nf_nat: remove obsolete check in nf_nat_mangle_udp_packet() kaber
2011-11-24 16:57 ` [PATCH 07/18] netfilter: ctnetlink: remove dead NAT code kaber
2011-11-24 16:57 ` [PATCH 08/18] netfilter: conntrack: restrict NAT helper invocation to IPv4 kaber
2011-11-24 16:57 ` [PATCH 09/18] netfilter: nf_nat: add protoff argument to packet mangling functions kaber
2011-11-24 16:57 ` [PATCH 10/18] netfilter: add protocol independant NAT core kaber
2011-11-24 16:57 ` [PATCH 11/18] netfilter: ipv6: expand skb head in ip6_route_me_harder after oif change kaber
2011-11-24 16:57 ` [PATCH 12/18] net: core: add function for incremental IPv6 pseudo header checksum updates kaber
2011-11-24 16:57 ` [PATCH 13/18] netfilter: ipv6: add IPv6 NAT support kaber
2011-11-24 16:57 ` [PATCH 14/18] netfilter: ip6tables: add MASQUERADE target kaber
2011-11-24 16:57 ` [PATCH 15/18] netfilter: ip6tables: add REDIRECT target kaber
2011-11-24 16:57 ` [PATCH 16/18] netfilter: ip6tables: add NETMAP target kaber
2011-11-24 16:57 ` [PATCH 17/18] netfilter: nf_nat: support IPv6 in FTP NAT helper kaber
2011-11-24 16:57 ` [PATCH 18/18] netfilter: nf_nat: support IPv6 in amanda " kaber
2011-11-28 17:14 ` [RFC PATCH 00/18] netfilter: IPv6 NAT Stephen Clark
2011-11-28 20:25 ` Ulrich Weber
2011-11-28 20:55 ` richard -rw- weinberger
2011-11-28 22:03 ` Amos Jeffries
2011-11-29 9:19 ` Ulrich Weber
2011-11-29 12:23 ` Jan Engelhardt
2011-11-29 13:24 ` Amos Jeffries
2011-11-29 21:38 ` Krzysztof Olędzki
2011-11-29 22:15 ` Eric Dumazet
2011-11-29 23:59 ` Krzysztof Olędzki
2011-11-29 22:21 ` Jan Engelhardt
2011-11-30 0:21 ` Krzysztof Olędzki
2011-11-30 10:07 ` Jan Engelhardt
2011-12-01 7:01 ` Krzysztof Olędzki
2011-11-30 0:05 ` Ben Hutchings
2011-11-30 0:30 ` Krzysztof Olędzki [this message]
2011-11-29 12:32 ` Patrick McHardy
2011-12-23 13:08 ` Pablo Neira Ayuso
-- strict thread matches above, loose matches on Subject: below --
2011-11-29 12:50 Re[2]: " Hans Schillstrom
2011-11-29 14:05 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ED5793E.1090003@ans.pl \
--to=ole@ans.pl \
--cc=bhutchings@solarflare.com \
--cc=jengelh@medozas.de \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=sclark46@earthlink.net \
--cc=squid3@treenet.co.nz \
--cc=ulrich.weber@sophos.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).