Re[2]: [RFC PATCH 00/18] netfilter: IPv6 NAT

Re[2]: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Hans Schillstrom]

>
>On 28.11.2011 18:14, Stephen Clark wrote:
>> On 11/24/2011 11:57 AM, kaber@trash.net wrote:
>>> The following patches contain the updated IPv6 NAT patchset forward
>>> ported
>>> to 3.2-rc3. ...
>>>
>>>
>>>    
>> Probabably a dumb question but are these patches for natting ipv6 to
>> ipv6 or ipv4 to ipv6?
>
>IPv6 to IPv6. I haven't really considered IPv6 to IPv4 yet.

Have you ever tried  ivi  The IPv6 to IPv4 gateway ?
i.e  address mapping and packet translation between IPv4 and IPv6 networks 

I made a port to resent kernel  in the begining of this year ( i think it was 2.6.36 ... ) and it seems to work.
(however there is some issues left....)

I like the idea of "ivi"  for a larger scale of translation.

/Hans

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Patrick McHardy]

On 11/29/2011 01:50 PM, Hans Schillstrom wrote:
>>> Probabably a dumb question but are these patches for natting ipv6 to
>>> ipv6 or ipv4 to ipv6?
>> IPv6 to IPv6. I haven't really considered IPv6 to IPv4 yet.
> Have you ever tried  ivi  The IPv6 to IPv4 gateway ?
> i.e  address mapping and packet translation between IPv4 and IPv6 networks

No, I'm currently looking at stateless IPv6 NAT mechanisms.

> I made a port to resent kernel  in the begining of this year ( i think it was 2.6.36 ... ) and it seems to work.
> (however there is some issues left....)
>
> I like the idea of "ivi"  for a larger scale of translation.

Do you have a pointer to your port?

[RFC PATCH 00/18] netfilter: IPv6 NAT

[kaber]

The following patches contain the updated IPv6 NAT patchset forward ported
to 3.2-rc3. Changes since last posting:

- Layer 4 protocol registration has been fixed to work properly with modular
  layer 4 protocol modules

- an inverted condition in the ip6t_NETMAP checkentry function causing
  rule addition to always fail has been fixed

- use of HH_DATA_ALIGN in IPv6 headroom reallocation after rerouting to fix
  unaligned data access on Tile, as suggested by Eric

- nla_policy fix has been moved to a separate patch

The patchset is also available at:

git://github.com/kaber/nf-nat-ipv6.git master

Last open point is IPv6 fragmentation handling, I'll implement my suggested
method of storing the biggest fragment size seen during reassembly in the CB
and using that as a hard limit during refragmentation over the weekend.


Patrick McHardy (18):
      netfilter: nf_nat: export NAT definitions to userspace
      netfilter: nf_nat: use hash random for bysource hash
      netfilter: nf_nat: add missing nla_policy entry for CTA_NAT_PROTO attribute
      netfilter: nat: remove module reference counting from NAT protocols
      netfilter: nf_nat: remove obsolete code from nf_nat_icmp_reply_translation()
      netfilter: nf_nat: remove obsolete check in nf_nat_mangle_udp_packet()
      netfilter: ctnetlink: remove dead NAT code
      netfilter: conntrack: restrict NAT helper invocation to IPv4
      netfilter: nf_nat: add protoff argument to packet mangling functions
      netfilter: add protocol independant NAT core
      netfilter: ipv6: expand skb head in ip6_route_me_harder after oif change
      net: core: add function for incremental IPv6 pseudo header checksum updates
      netfilter: ipv6: add IPv6 NAT support
      netfilter: ip6tables: add MASQUERADE target
      netfilter: ip6tables: add REDIRECT target
      netfilter: ip6tables: add NETMAP target
      netfilter: nf_nat: support IPv6 in FTP NAT helper
      netfilter: nf_nat: support IPv6 in amanda NAT helper

 include/linux/netfilter.h                          |   14 +-
 include/linux/netfilter/Kbuild                     |    1 +
 include/linux/netfilter/nf_conntrack_amanda.h      |    1 +
 include/linux/netfilter/nf_conntrack_ftp.h         |    1 +
 include/linux/netfilter/nf_conntrack_h323.h        |   15 +-
 include/linux/netfilter/nf_conntrack_irc.h         |    1 +
 include/linux/netfilter/nf_conntrack_pptp.h        |    2 +
 include/linux/netfilter/nf_conntrack_sip.h         |   12 +-
 .../linux/netfilter/nf_conntrack_tuple_common.h    |   27 +
 include/linux/netfilter/nf_nat.h                   |   33 +
 include/linux/netfilter/nfnetlink_conntrack.h      |    8 +-
 include/linux/netfilter_ipv4.h                     |    1 -
 include/linux/netfilter_ipv4/Kbuild                |    1 -
 include/linux/netfilter_ipv4/nf_nat.h              |   58 --
 include/net/addrconf.h                             |    2 +-
 include/net/checksum.h                             |    3 +
 include/net/netfilter/nf_conntrack_expect.h        |    2 +-
 include/net/netfilter/nf_conntrack_tuple.h         |    1 -
 include/net/netfilter/nf_nat.h                     |    8 +-
 include/net/netfilter/nf_nat_core.h                |    7 +-
 include/net/netfilter/nf_nat_helper.h              |   11 +-
 include/net/netfilter/nf_nat_l3proto.h             |   52 ++
 include/net/netfilter/nf_nat_l4proto.h             |   72 +++
 include/net/netfilter/nf_nat_protocol.h            |   74 ---
 include/net/netfilter/nf_nat_rule.h                |   15 -
 include/net/netns/conntrack.h                      |    4 +
 include/net/netns/ipv4.h                           |    2 -
 include/net/netns/ipv6.h                           |    1 +
 net/core/secure_seq.c                              |    1 +
 net/core/utils.c                                   |   20 +
 net/ipv4/netfilter.c                               |   37 --
 net/ipv4/netfilter/Kconfig                         |   67 +--
 net/ipv4/netfilter/Makefile                        |   13 +-
 net/ipv4/netfilter/ipt_MASQUERADE.c                |   26 +-
 net/ipv4/netfilter/ipt_NETMAP.c                    |   21 +-
 net/ipv4/netfilter/ipt_REDIRECT.c                  |   23 +-
 .../{nf_nat_standalone.c => iptable_nat.c}         |  266 ++++-----
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c     |    8 +-
 net/ipv4/netfilter/nf_nat_h323.c                   |   83 ++--
 net/ipv4/netfilter/nf_nat_irc.c                    |    4 +-
 net/ipv4/netfilter/nf_nat_l3proto_ipv4.c           |  281 +++++++++
 net/ipv4/netfilter/nf_nat_pptp.c                   |   31 +-
 net/ipv4/netfilter/nf_nat_proto_common.c           |  126 ----
 net/ipv4/netfilter/nf_nat_proto_gre.c              |   36 +-
 net/ipv4/netfilter/nf_nat_proto_icmp.c             |   26 +-
 net/ipv4/netfilter/nf_nat_rule.c                   |  214 -------
 net/ipv4/netfilter/nf_nat_sip.c                    |  121 ++--
 net/ipv4/netfilter/nf_nat_tftp.c                   |    1 -
 net/ipv6/addrconf.c                                |    2 +-
 net/ipv6/netfilter.c                               |    8 +
 net/ipv6/netfilter/Kconfig                         |   48 ++
 net/ipv6/netfilter/Makefile                        |    7 +
 net/ipv6/netfilter/ip6t_MASQUERADE.c               |  135 +++++
 net/ipv6/netfilter/ip6t_NETMAP.c                   |   94 +++
 net/ipv6/netfilter/ip6t_REDIRECT.c                 |   98 +++
 net/ipv6/netfilter/ip6table_nat.c                  |  319 ++++++++++
 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c     |   14 +
 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c           |  285 +++++++++
 net/ipv6/netfilter/nf_nat_proto_icmpv6.c           |   87 +++
 net/netfilter/Kconfig                              |   34 ++
 net/netfilter/Makefile                             |   15 +
 net/netfilter/core.c                               |    5 +
 net/netfilter/ipvs/ip_vs_ftp.c                     |    1 +
 net/netfilter/nf_conntrack_amanda.c                |    5 +-
 net/netfilter/nf_conntrack_core.c                  |    7 +
 net/netfilter/nf_conntrack_ftp.c                   |    3 +-
 net/netfilter/nf_conntrack_h323_main.c             |  232 +++++---
 net/netfilter/nf_conntrack_irc.c                   |    6 +-
 net/netfilter/nf_conntrack_netlink.c               |   30 +-
 net/netfilter/nf_conntrack_pptp.c                  |   18 +-
 net/netfilter/nf_conntrack_proto_tcp.c             |    8 +-
 net/netfilter/nf_conntrack_sip.c                   |  119 +++--
 net/netfilter/nf_conntrack_tftp.c                  |    3 +-
 net/{ipv4 => }/netfilter/nf_nat_amanda.c           |    4 +-
 net/{ipv4 => }/netfilter/nf_nat_core.c             |  621 ++++++++++----------
 net/{ipv4 => }/netfilter/nf_nat_ftp.c              |   33 +-
 net/{ipv4 => }/netfilter/nf_nat_helper.c           |  121 ++---
 net/netfilter/nf_nat_proto_common.c                |  112 ++++
 net/{ipv4 => }/netfilter/nf_nat_proto_dccp.c       |   58 +-
 net/{ipv4 => }/netfilter/nf_nat_proto_sctp.c       |   55 +-
 net/{ipv4 => }/netfilter/nf_nat_proto_tcp.c        |   42 +-
 net/{ipv4 => }/netfilter/nf_nat_proto_udp.c        |   44 +-
 net/{ipv4 => }/netfilter/nf_nat_proto_udplite.c    |   60 +-
 net/{ipv4 => }/netfilter/nf_nat_proto_unknown.c    |   15 +-
 net/netfilter/xt_nat.c                             |  185 ++++++
 85 files changed, 3132 insertions(+), 1635 deletions(-)

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Stephen Clark]

On 11/24/2011 11:57 AM, kaber@trash.net wrote:
> The following patches contain the updated IPv6 NAT patchset forward ported
> to 3.2-rc3. Changes since last posting:
>
> - Layer 4 protocol registration has been fixed to work properly with modular
>    layer 4 protocol modules
>
> - an inverted condition in the ip6t_NETMAP checkentry function causing
>    rule addition to always fail has been fixed
>
> - use of HH_DATA_ALIGN in IPv6 headroom reallocation after rerouting to fix
>    unaligned data access on Tile, as suggested by Eric
>
> - nla_policy fix has been moved to a separate patch
>
> The patchset is also available at:
>
> git://github.com/kaber/nf-nat-ipv6.git master
>
> Last open point is IPv6 fragmentation handling, I'll implement my suggested
> method of storing the biggest fragment size seen during reassembly in the CB
> and using that as a hard limit during refragmentation over the weekend.
>
>
> Patrick McHardy (18):
>        netfilter: nf_nat: export NAT definitions to userspace
>        netfilter: nf_nat: use hash random for bysource hash
>        netfilter: nf_nat: add missing nla_policy entry for CTA_NAT_PROTO attribute
>        netfilter: nat: remove module reference counting from NAT protocols
>        netfilter: nf_nat: remove obsolete code from nf_nat_icmp_reply_translation()
>        netfilter: nf_nat: remove obsolete check in nf_nat_mangle_udp_packet()
>        netfilter: ctnetlink: remove dead NAT code
>        netfilter: conntrack: restrict NAT helper invocation to IPv4
>        netfilter: nf_nat: add protoff argument to packet mangling functions
>        netfilter: add protocol independant NAT core
>        netfilter: ipv6: expand skb head in ip6_route_me_harder after oif change
>        net: core: add function for incremental IPv6 pseudo header checksum updates
>        netfilter: ipv6: add IPv6 NAT support
>        netfilter: ip6tables: add MASQUERADE target
>        netfilter: ip6tables: add REDIRECT target
>        netfilter: ip6tables: add NETMAP target
>        netfilter: nf_nat: support IPv6 in FTP NAT helper
>        netfilter: nf_nat: support IPv6 in amanda NAT helper
>
>   include/linux/netfilter.h                          |   14 +-
>   include/linux/netfilter/Kbuild                     |    1 +
>   include/linux/netfilter/nf_conntrack_amanda.h      |    1 +
>   include/linux/netfilter/nf_conntrack_ftp.h         |    1 +
>   include/linux/netfilter/nf_conntrack_h323.h        |   15 +-
>   include/linux/netfilter/nf_conntrack_irc.h         |    1 +
>   include/linux/netfilter/nf_conntrack_pptp.h        |    2 +
>   include/linux/netfilter/nf_conntrack_sip.h         |   12 +-
>   .../linux/netfilter/nf_conntrack_tuple_common.h    |   27 +
>   include/linux/netfilter/nf_nat.h                   |   33 +
>   include/linux/netfilter/nfnetlink_conntrack.h      |    8 +-
>   include/linux/netfilter_ipv4.h                     |    1 -
>   include/linux/netfilter_ipv4/Kbuild                |    1 -
>   include/linux/netfilter_ipv4/nf_nat.h              |   58 --
>   include/net/addrconf.h                             |    2 +-
>   include/net/checksum.h                             |    3 +
>   include/net/netfilter/nf_conntrack_expect.h        |    2 +-
>   include/net/netfilter/nf_conntrack_tuple.h         |    1 -
>   include/net/netfilter/nf_nat.h                     |    8 +-
>   include/net/netfilter/nf_nat_core.h                |    7 +-
>   include/net/netfilter/nf_nat_helper.h              |   11 +-
>   include/net/netfilter/nf_nat_l3proto.h             |   52 ++
>   include/net/netfilter/nf_nat_l4proto.h             |   72 +++
>   include/net/netfilter/nf_nat_protocol.h            |   74 ---
>   include/net/netfilter/nf_nat_rule.h                |   15 -
>   include/net/netns/conntrack.h                      |    4 +
>   include/net/netns/ipv4.h                           |    2 -
>   include/net/netns/ipv6.h                           |    1 +
>   net/core/secure_seq.c                              |    1 +
>   net/core/utils.c                                   |   20 +
>   net/ipv4/netfilter.c                               |   37 --
>   net/ipv4/netfilter/Kconfig                         |   67 +--
>   net/ipv4/netfilter/Makefile                        |   13 +-
>   net/ipv4/netfilter/ipt_MASQUERADE.c                |   26 +-
>   net/ipv4/netfilter/ipt_NETMAP.c                    |   21 +-
>   net/ipv4/netfilter/ipt_REDIRECT.c                  |   23 +-
>   .../{nf_nat_standalone.c =>  iptable_nat.c}         |  266 ++++-----
>   net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c     |    8 +-
>   net/ipv4/netfilter/nf_nat_h323.c                   |   83 ++--
>   net/ipv4/netfilter/nf_nat_irc.c                    |    4 +-
>   net/ipv4/netfilter/nf_nat_l3proto_ipv4.c           |  281 +++++++++
>   net/ipv4/netfilter/nf_nat_pptp.c                   |   31 +-
>   net/ipv4/netfilter/nf_nat_proto_common.c           |  126 ----
>   net/ipv4/netfilter/nf_nat_proto_gre.c              |   36 +-
>   net/ipv4/netfilter/nf_nat_proto_icmp.c             |   26 +-
>   net/ipv4/netfilter/nf_nat_rule.c                   |  214 -------
>   net/ipv4/netfilter/nf_nat_sip.c                    |  121 ++--
>   net/ipv4/netfilter/nf_nat_tftp.c                   |    1 -
>   net/ipv6/addrconf.c                                |    2 +-
>   net/ipv6/netfilter.c                               |    8 +
>   net/ipv6/netfilter/Kconfig                         |   48 ++
>   net/ipv6/netfilter/Makefile                        |    7 +
>   net/ipv6/netfilter/ip6t_MASQUERADE.c               |  135 +++++
>   net/ipv6/netfilter/ip6t_NETMAP.c                   |   94 +++
>   net/ipv6/netfilter/ip6t_REDIRECT.c                 |   98 +++
>   net/ipv6/netfilter/ip6table_nat.c                  |  319 ++++++++++
>   net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c     |   14 +
>   net/ipv6/netfilter/nf_nat_l3proto_ipv6.c           |  285 +++++++++
>   net/ipv6/netfilter/nf_nat_proto_icmpv6.c           |   87 +++
>   net/netfilter/Kconfig                              |   34 ++
>   net/netfilter/Makefile                             |   15 +
>   net/netfilter/core.c                               |    5 +
>   net/netfilter/ipvs/ip_vs_ftp.c                     |    1 +
>   net/netfilter/nf_conntrack_amanda.c                |    5 +-
>   net/netfilter/nf_conntrack_core.c                  |    7 +
>   net/netfilter/nf_conntrack_ftp.c                   |    3 +-
>   net/netfilter/nf_conntrack_h323_main.c             |  232 +++++---
>   net/netfilter/nf_conntrack_irc.c                   |    6 +-
>   net/netfilter/nf_conntrack_netlink.c               |   30 +-
>   net/netfilter/nf_conntrack_pptp.c                  |   18 +-
>   net/netfilter/nf_conntrack_proto_tcp.c             |    8 +-
>   net/netfilter/nf_conntrack_sip.c                   |  119 +++--
>   net/netfilter/nf_conntrack_tftp.c                  |    3 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_amanda.c           |    4 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_core.c             |  621 ++++++++++----------
>   net/{ipv4 =>  }/netfilter/nf_nat_ftp.c              |   33 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_helper.c           |  121 ++---
>   net/netfilter/nf_nat_proto_common.c                |  112 ++++
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_dccp.c       |   58 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_sctp.c       |   55 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_tcp.c        |   42 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_udp.c        |   44 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_udplite.c    |   60 +-
>   net/{ipv4 =>  }/netfilter/nf_nat_proto_unknown.c    |   15 +-
>   net/netfilter/xt_nat.c                             |  185 ++++++
>   85 files changed, 3132 insertions(+), 1635 deletions(-)
>
> --
> 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
>
>    
Probabably a dumb question but are these patches for natting ipv6 to 
ipv6 or ipv4 to ipv6?

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Ulrich Weber]

Am 28.11.11 18:14 schrieb "Stephen Clark" unter <sclark46@earthlink.net>:
 
>Probabably a dumb question but are these patches for natting ipv6 to
>ipv6 or ipv4 to ipv6?

These patches are for natting IPv6 addresses behind whole IPv6 subnets
or just behind one IPv6 address.

This is useful for multiple Internet uplinks, where you want full control
on the router what connections are sent over which interface. Or its quite
easy to setup Load Balancing rules or create a DMZ. There a lots of use
casesŠ


If you are looking for IPv4->IPv6 or IPv6->IPv4, there are multiple
implementations. Two examples:

IPv6->IPv4:

http://ecdysis.viagenie.ca

IPv4->IPv6:
http://www.ivi2.org


Best regards
 Ulrich

--
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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[richard -rw- weinberger]

On Mon, Nov 28, 2011 at 9:25 PM, Ulrich Weber <Ulrich.Weber@sophos.com> wrote:
> IPv6->IPv4:
>
> http://ecdysis.viagenie.ca

Is this solution stable?
The last time I've tested it it had no SMP locking at all...

-- 
Thanks,
//richard

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Amos Jeffries]

 On Mon, 28 Nov 2011 20:25:48 +0000, Ulrich Weber wrote:
> Am 28.11.11 18:14 schrieb "Stephen Clark" unter:
>
>>Probabably a dumb question but are these patches for natting ipv6 to
>>ipv6 or ipv4 to ipv6?
>
> These patches are for natting IPv6 addresses behind whole IPv6 
> subnets
> or just behind one IPv6 address.
>
> This is useful for multiple Internet uplinks, where you want full 
> control
> on the router what connections are sent over which interface. Or its 
> quite
> easy to setup Load Balancing rules or create a DMZ. There a lots of 
> use
> casesŠ

 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.

  * outgoing packet control - packets will happily leave the "wrong" 
 interface after NAT unless you add routing and firewall controls 
 separate to NAT. Packet control works *better* without NAT erasing 
 original IP information resulting in mistakenly NAT'ed packets go out 
 the wrong interface.


 I have long been of the opinion that all NAT really offers is the 
 ability to easily and cleanly multi-home several global public prefixes 
 from a unified PI space. This is a very important aspect for some 
 networks, even with plentiful IPv6 addresses.

 Claims and use of NAT as a security, load balancing, and routing 
 control is where most of the nasty side effects and behaviours are 
 streaming in from.

 AYJ

--
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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Ulrich Weber]

Please dont' let this deviate to a flame war.
I just said there are use cases, nothing more, nothing less.

This is software. There are lots of ways to archive the same goal.
Every solution has its pro and cons, its not always black and white.


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.
>
Nothing, you archive the same in a different way.
However keep in mind that not all computers out there run Linux.

Its quite simple to setup NAT rules, they work with every OS.

On the other hand, balancing by changing MAC address or
IPv6inIPv6 Tunnels can be a headache, getting this going with
Windows, Mac, Solaris and so on.

Issues with DAD and source address selection doesn't make it easier.
Have a look at net/netfilter/ipvs/ip_vs_xmit.c. There is a reason, why
NAT for IPv6 is already in the Kernel since three years.

>    * outgoing packet control - packets will happily leave the "wrong"
>   interface after NAT unless you add routing and firewall controls
>   separate to NAT. Packet control works *better* without NAT erasing
>   original IP information resulting in mistakenly NAT'ed packets go out
>   the wrong interface.
>
>
I fully agree. NAT can not replace your firewall rules.

However with NAT you could get some kind of anonymity.
Think of Tor: If your server/client operates with private IP addresses,
your public IP address is still masked after a security breach.

>   I have long been of the opinion that all NAT really offers is the
>   ability to easily and cleanly multi-home several global public prefixes
>   from a unified PI space. This is a very important aspect for some
>   networks, even with plentiful IPv6 addresses.
Also in my opinion the most important reason for NAT.

Cheers
  Ulrich

-- 
Ulrich Weber | ulrich.weber@sophos.com | Senior Software Engineer
Astaro - a Sophos company | Amalienbadstr 41 | 76227 Karlsruhe | Germany
Phone +49-721-25516-0 | Fax –200 | www.astaro.com

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Jan Engelhardt]

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.

Everybody should come out of their worshipping NAT for anonymity
now - at best, that is an Emperor's Clothes' kind of anonymity.

> Think of Tor: If your server/client operates with private IP addresses,
> your public IP address is still masked after a security breach.

If one's tor peer was busted, they would have the address.

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Amos Jeffries]

On 30/11/2011 1:23 a.m., 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,

There you are adding a straw-man component into the mix. "Given two 
uplinks that only allow a certain source network address ", yes I agree, 
NAT is the sugar that makes these uplinks work. Irrelevant of load 
balancing.

In the same way the security != NAT, so too load balancing != NAT. As 
I'm sure you are all well aware.

Looking back at Ulrichs' original statement after reading yours it's 
clear he probably meant that (I hope so at least). The first reading 
though was that NAT by itself provided easy load balancing and DMZ.  I 
argue neither for or against validity of NAT. Just the Fuzziness 
Uncertainty and Doubt created by the particular statement was of a high 
amount.

>   (b) the clients needs
> to cooperate, and one cannot always trust client devices, or hope for
> their technical cooperation (firewalled themselves off).
>
>

>> 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.
>
> Everybody should come out of their worshipping NAT for anonymity
> now - at best, that is an Emperor's Clothes' kind of anonymity.
>
>> Think of Tor: If your server/client operates with private IP addresses,
>> your public IP address is still masked after a security breach.
> If one's tor peer was busted, they would have the address.
> --
> 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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Krzysztof Olędzki]

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.

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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Eric Dumazet]

Le mardi 29 novembre 2011 à 22:38 +0100, Krzysztof Olędzki a écrit :

> 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.
> 

Good point, but we can change MAC address (use a random one) on most
NIC, cant we ?

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Krzysztof Olędzki]

On 2011-11-29 23:15, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 22:38 +0100, Krzysztof Olędzki a écrit :
>
>> 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.
>>
>
> Good point, but we can change MAC address (use a random one) on most
> NIC, cant we ?

Sure, but the problem is that you first need to know that you should do 
it and you need to be able to do it - think of cell phones, tablets, etc.

Best regards,

				Krzysztof Oledzki

--
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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Jan Engelhardt]

On Tuesday 2011-11-29 22:38, Krzysztof Olędzki wrote:
>>
>> 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.

Everywhere? No, one small village of indomitable Gauls.^^^^^^^^W

$ ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0d:93:9e:08:78 brd ff:ff:ff:ff:ff:ff
    inet6 2001:638:600:8810:d070:3a36:464e:b3db/64 scope global temporary dynamic 
       valid_lft 583732sec preferred_lft 64732sec
    inet6 2001:638:600:8810:d9f5:18f5:4fc1:9a20/64 scope global temporary deprecated dynamic 
       valid_lft 497938sec preferred_lft 0sec
    [...]

Same suffix? Certainly not with contemporary configurations (and
Linux did this quite on its own there). In fact, now that there is
almost v6-NAT in the kernel, I fear that users who are blinded by NAT
now make the problem worse by actually feeding perfectly good Privacy
Extension Addresses into a n:1-configured SNAT/MASQUERADE target
instead of a NETMAP.

> In your Home, your Work, in a Cafe or in
> a hotel during your vacations in Portugal.
--
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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Krzysztof Olędzki]

On 2011-11-29 23:21, Jan Engelhardt wrote:
>
> On Tuesday 2011-11-29 22:38, Krzysztof Olędzki wrote:
>>>
>>> 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.
>
> Everywhere? No, one small village of indomitable Gauls.^^^^^^^^W
>
> $ ip a
> 2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP>  mtu 1500 qdisc mq state UP qlen 1000
>      link/ether 00:0d:93:9e:08:78 brd ff:ff:ff:ff:ff:ff
>      inet6 2001:638:600:8810:d070:3a36:464e:b3db/64 scope global temporary dynamic
>         valid_lft 583732sec preferred_lft 64732sec
>      inet6 2001:638:600:8810:d9f5:18f5:4fc1:9a20/64 scope global temporary deprecated dynamic
>         valid_lft 497938sec preferred_lft 0sec
>      [...]
>
> Same suffix? Certainly not with contemporary configurations (and
> Linux did this quite on its own there). In fact, now that there is
> almost v6-NAT in the kernel, I fear that users who are blinded by NAT
> now make the problem worse by actually feeding perfectly good Privacy
> Extension Addresses into a n:1-configured SNAT/MASQUERADE target
> instead of a NETMAP.

What if:

1. You or your users don't have modern OS on your device so there is no 
DHCPv6 or rfc3041/4941 support?

2. It is not enabled by default and you are not aware of this?

3. You need to have static addresses in your network for access control?

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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Jan Engelhardt]

On Wednesday 2011-11-30 01:21, Krzysztof Olędzki wrote:
>>>
>>>>>However with NAT you could get some kind of anonymity.
>>>
>>>But without NAT you have pretty big chance to have the same IPv6 
>>>*suffix* everywhere, based on you MAC address. without NAT you have 
>>>pretty big chance to have the same IPv6 *suffix* everywhere, based on 
>>>you MAC address.
>>
>>Same suffix? Certainly not with [PrivExt...]
>
>What if:
>
>1. You or your users don't have modern OS on your device so there is no 
>DHCPv6 or rfc3041/4941 support?

Dedicated separate program (that's what you would probably do on
Windows XP which lacks DHCPv6, PrivExt and also does not even allow
manually setting an address via GUI).

>3. You need to have static addresses in your network for access control?

Access control can be done based on MAC within a broadcast domain so
you don't have to eschew Privacy Extensions if you can do so.
--
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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Krzysztof Olędzki]

On 2011-11-30 11:07, Jan Engelhardt wrote:
>
> On Wednesday 2011-11-30 01:21, Krzysztof Olędzki wrote:
>>>>
>>>>>> However with NAT you could get some kind of anonymity.
>>>>
>>>> But without NAT you have pretty big chance to have the same IPv6
>>>> *suffix* everywhere, based on you MAC address. without NAT you have
>>>> pretty big chance to have the same IPv6 *suffix* everywhere, based on
>>>> you MAC address.
>>>
>>> Same suffix? Certainly not with [PrivExt...]
>>
>> What if:
>>
>> 1. You or your users don't have modern OS on your device so there is no
>> DHCPv6 or rfc3041/4941 support?
>
> Dedicated separate program (that's what you would probably do on
> Windows XP which lacks DHCPv6, PrivExt and also does not even allow
> manually setting an address via GUI).

Too much effort. Really.

>> 3. You need to have static addresses in your network for access control?
>
> Access control can be done based on MAC within a broadcast domain so
> you don't have to eschew Privacy Extensions if you can do so.

Maybe if you have a very small network - just one or two subnets, one 
router... Again - maybe. It is definitely not going to work on a large, 
multisite network with many intermediate routers.

All you can do on edge devices is checking client's MAC, requring 802.1X 
and making sure that IP matches MAC (and possibly DHCP lease) and 
similar things.

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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Ben Hutchings]

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.

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Krzysztof Olędzki]

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

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Patrick McHardy]

On 28.11.2011 18:14, Stephen Clark wrote:
> On 11/24/2011 11:57 AM, kaber@trash.net wrote:
>> The following patches contain the updated IPv6 NAT patchset forward
>> ported
>> to 3.2-rc3. ...
>>
>>
>>    
> Probabably a dumb question but are these patches for natting ipv6 to
> ipv6 or ipv4 to ipv6?

IPv6 to IPv6. I haven't really considered IPv6 to IPv4 yet.

Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

[Pablo Neira Ayuso]

Hi Patrick,

On Thu, Nov 24, 2011 at 05:57:11PM +0100, kaber@trash.net wrote:
> The following patches contain the updated IPv6 NAT patchset forward ported
> to 3.2-rc3.

I've applied patches from 1 to 7. They are independent of the
IPv6 NAT support so they are safe to be applied.

Please, rebase your tree once they have hit davem's tree. Make sure
you rebase your tree before final submission of the IPv6 NAT support.

Thanks!