netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: "Krzysztof Olędzki" <ole@ans.pl>
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 00:05:09 +0000	[thread overview]
Message-ID: <1322611509.2684.52.camel@bwh-desktop> (raw)
In-Reply-To: <4ED550E7.1090609@ans.pl>

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?

Instead you need to deal with this on the mobile device itself, using
the RFC3041 privacy extensions.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

  parent reply	other threads:[~2011-11-30  0:05 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 [this message]
2011-11-30  0:30               ` Krzysztof Olędzki
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=1322611509.2684.52.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=jengelh@medozas.de \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=ole@ans.pl \
    --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).