NAT for IPv6

NAT for IPv6

[Maciej Soltysiak]

Hello,

out of curiousity - are there plans to incorporate NAT into ip6tables
or future pkttables ?

Regards,
Maciej

Re: NAT for IPv6

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Wed, Nov 19, 2003 at 01:38:47PM +0100, Maciej Soltysiak wrote:
> Hello,
> 
> out of curiousity - are there plans to incorporate NAT into ip6tables
> or future pkttables ?

over my dead body.  NAT is what broke ipv4 end-to-end.  Let's not do the
same with ipv6.

The only reasonable application is ipv4-to-ipv6 transition-nat.

> Regards,
> Maciej

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: NAT for IPv6

[Emmanuel Guiton]

Harald Welte wrote:

> On Wed, Nov 19, 2003 at 01:38:47PM +0100, Maciej Soltysiak wrote:
>  
>
>> Hello,
>>
>> out of curiousity - are there plans to incorporate NAT into ip6tables
>> or future pkttables ?
>>   
>
>
> over my dead body.  NAT is what broke ipv4 end-to-end.  Let's not do the
> same with ipv6.
>
> The only reasonable application is ipv4-to-ipv6 transition-nat.
>  
>

I wonder... Can every NAT applications be replaced by ipv6? Now, the 
application area of NAT is much bigger than the original goals (e.g. 
security applications, easing network administration), so I wonder if 
ipv6 can make NAT useless. Without proof of the contrary I would say 
that NAT will still be usefull.

              Emmanuel

Re: NAT for IPv6

[Balazs Scheidler]

On Thu, Nov 20, 2003 at 02:40:42PM +0100, Harald Welte wrote:
> On Wed, Nov 19, 2003 at 01:38:47PM +0100, Maciej Soltysiak wrote:
> > Hello,
> > 
> > out of curiousity - are there plans to incorporate NAT into ip6tables
> > or future pkttables ?
> 
> over my dead body.  NAT is what broke ipv4 end-to-end.  Let's not do the
> same with ipv6.
> 
> The only reasonable application is ipv4-to-ipv6 transition-nat.

s/transition-nat\./transition-nat, and local NAT necessary for TPROXY to work./

please.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: NAT for IPv6

[Henrik Nordstrom]

On Thu, 20 Nov 2003, Emmanuel Guiton wrote:

> I wonder... Can every NAT applications be replaced by ipv6? Now, the 
> application area of NAT is much bigger than the original goals (e.g. 
> security applications, easing network administration), so I wonder if 
> ipv6 can make NAT useless. Without proof of the contrary I would say 
> that NAT will still be usefull.

Lets put it this way instead:

Now that we are on the edge of starting to deploy a new Internet network
addressing scheme, try not to repeat the mistakes done in IPv4 in IPv6
only because they happens to solve what it thought to be real problems in
IPv4, such as abusing NAT for other purposes than NAT was intended for.
IPv6 completely eleminates the original purpose of NAT (compression of 
the IPv4 address space).

It is true that NAT in IPv4 is used for a lot of other applications today
than was originally envisioned when designing NAT for IPv4, but most is
there to work around application protocol braindamage, not to solve IPv4
level networking problems. Some of these applications are pretty neat such
as server load balancing, but still using NAT for such purposes is
fundamentally broken from a IPv4 networking point of view.

Undoubtly similar abuses of the IPv6 protocol to do "amasing" things is
likely to appear over time just as has had happened with IPv4 in the last
decade, but it is pointless to start discussing breaking the protocol
before investigating what solutions exists for solving the problem within
the protocol. A lot of thought has been put into the IPv6 protocol to
solve many of the problems experienced over the years with IPv4, and at
the same time the transition from IPv4 to IPv6 also allows for a nice
transition from old braindead applications to more capable applications.

So instead of focusing on IPv4 problems in a IPv6 packet level, take a
step back and look at the problem as such and how it is best solved in
IPv6. If this involves slight changes to applications to add behaviour not
yet existing, no big deal as the applications need to be changed anyway.

Regards
Henrik

Re: NAT for IPv6

[Henrik Nordstrom]

On Thu, 20 Nov 2003, Balazs Scheidler wrote:

> s/transition-nat\./transition-nat, and local NAT necessary for TPROXY to work./

TPROXY is a prime example of breaking the end-to-end MUST requirement of
IPv4 networking. Such abuses of the IPv4 protocol is actually among the 
worst.

TPROXY like designs should at best be seen as a temporary solution to a
problem, not a permanent solution.

Note that I here speak about the IP level, not the implementation quality 
of the TPROXY support in netfilter/iptables. 

Lets at least try to solve the kinds of problems TPROXY and similar tools 
tries to solve in the IPv4 protocol by using the capabilities and 
opportunities provided by the IPv6 transition before starting to break the 
design of the IP protocol again.

Regards
Henrik

Re: NAT for IPv6

[Balazs Scheidler]

On Thu, Nov 20, 2003 at 04:48:37PM +0100, Henrik Nordstrom wrote:
> On Thu, 20 Nov 2003, Balazs Scheidler wrote:
> 
> > s/transition-nat\./transition-nat, and local NAT necessary for TPROXY to work./
> 
> TPROXY is a prime example of breaking the end-to-end MUST requirement of
> IPv4 networking. Such abuses of the IPv4 protocol is actually among the 
> worst.
> 
> TPROXY like designs should at best be seen as a temporary solution to a
> problem, not a permanent solution.

And what do you think of the problem is? We are using TPROXY to create proxy
based firewalls, analyzing the network flows at the application level.
Proxies run in userspace moving a complex function out of the kernel (NAT
helpers)

TPROXY is not only meant to transparently proxy HTTP. Performing virus
checking in a POP3 flow encrypted using SSL is not possible using packet
filtering. (but it is using proxies)

> Lets at least try to solve the kinds of problems TPROXY and similar tools 
> tries to solve in the IPv4 protocol by using the capabilities and 
> opportunities provided by the IPv6 transition before starting to break the 
> design of the IP protocol again.

I still can't see what you think the "kinds of problems TPROXY and silimar
tools try to solve" is.

We (and our customers) have the following requirements:

- application layer verification (URL filtering, virus checking, tasks that
  are difficult/impossible to solve from kernel space)
- transparency
  - because there are protocols which do not have a proxy mode 
  - because they do not want to reconfigure their clients when a firewall
    is installed.

I can see cases when end-to-end IP connections are a must, but there are
other cases when proxying is the only viable solution, and I can't see why
we can't have a solution for both worlds.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: NAT for IPv6

[Balazs Scheidler]

On Thu, Nov 20, 2003 at 04:43:05PM +0100, Henrik Nordstrom wrote:
> On Thu, 20 Nov 2003, Emmanuel Guiton wrote:
> Undoubtly similar abuses of the IPv6 protocol to do "amasing" things is
> likely to appear over time just as has had happened with IPv4 in the last
> decade, but it is pointless to start discussing breaking the protocol
> before investigating what solutions exists for solving the problem within
> the protocol. A lot of thought has been put into the IPv6 protocol to
> solve many of the problems experienced over the years with IPv4, and at
> the same time the transition from IPv4 to IPv6 also allows for a nice
> transition from old braindead applications to more capable applications.
> 
> So instead of focusing on IPv4 problems in a IPv6 packet level, take a
> step back and look at the problem as such and how it is best solved in
> IPv6. If this involves slight changes to applications to add behaviour not
> yet existing, no big deal as the applications need to be changed anyway.

You might be right in some circumstances, the problem is _existing_
applications are being ported to IPv6 which carry on their legacy problems.

I can't see the trend that introducing IPv6 would replace all protocols in
use today (POP3, IMAP, SMTP, etc.)

They will have their security implications just like in their IPv4
equivalent. 

And adding explicit proxying to the protocol will not give you end-to-end IP
either.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: NAT for IPv6

[Henrik Nordstrom]

On Thu, 20 Nov 2003, Balazs Scheidler wrote:

> I still can't see what you think the "kinds of problems TPROXY and silimar
> tools try to solve" is.

In case of TPROXY it is any problem where you need to have traffic
terminated at another place than the intended destination server for
whatever reason without the knowledge of the sender. This is outside of IP
specifications for very good reasons.

I don't see TPROXY or other interception techniques as that bad if every
single packet is intercepted. If it is used for selective interception of
only certain ports or similar then it is a different beast.

> We (and our customers) have the following requirements:
> 
> - application layer verification (URL filtering, virus checking, tasks that
>   are difficult/impossible to solve from kernel space)

Yes.

> - transparency
>   - because there are protocols which do not have a proxy mode 
>   - because they do not want to reconfigure their clients when a firewall
>     is installed.

And these points I say should not be taken for granted when moving to a 
IPv6 environment.

There is very few protocols which can not be proxied using the proper 
tools. And given some thought clients should not be needed to be manually 
reconfigured when installing a firewall.

> I can see cases when end-to-end IP connections are a must, but there are
> other cases when proxying is the only viable solution, and I can't see why
> we can't have a solution for both worlds.

I am not against proxying (quite naturally given who I am). What I am
against is violation of the fundamental end-to-end property of IP. Per
definition proxying is not a violation of end-to-end, transparent
interception is.

In the state of IPv4 it is unfortunately a neccesary bad due to the large
installed base of dumb applications not capable of using proxies. The
situation in IPv6 is better and in my opinion in a position allowing this
kind of problems to be solved at the application level without having to 
resort to "dirty hacks".

Regards
Henrik

Re: NAT for IPv6

[Balazs Scheidler]

Hi,

[Removed direct Cc's and left netfilter-devel as this topic might not be too
interesting to them]

On Fri, Nov 21, 2003 at 01:24:15AM +0100, Henrik Nordstrom wrote:
> > - transparency
> >   - because there are protocols which do not have a proxy mode 
> >   - because they do not want to reconfigure their clients when a firewall
> >     is installed.
> 
> And these points I say should not be taken for granted when moving to a 
> IPv6 environment.
> 
> There is very few protocols which can not be proxied using the proper 
> tools. And given some thought clients should not be needed to be manually 
> reconfigured when installing a firewall.

I can't how this would be implemented when a legacy protocol is ported. 

> 
> > I can see cases when end-to-end IP connections are a must, but there are
> > other cases when proxying is the only viable solution, and I can't see why
> > we can't have a solution for both worlds.
> 
> I am not against proxying (quite naturally given who I am). What I am
> against is violation of the fundamental end-to-end property of IP. Per
> definition proxying is not a violation of end-to-end, transparent
> interception is.

In my sense firewalls have nothing but a DROP rule in their FORWARD chain,
and I can't see how end-to-end IP communication can be established through a
DROP rule :)

> In the state of IPv4 it is unfortunately a neccesary bad due to the large
> installed base of dumb applications not capable of using proxies. The
> situation in IPv6 is better and in my opinion in a position allowing this
> kind of problems to be solved at the application level without having to 
> resort to "dirty hacks".

I think there are too many legacy application protocols being ported
to IPv6 without any application layer change.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: NAT for IPv6

[Don Cohen]

I'm missing something very basic.
Could someone please explain (or send a reference that explains)
the end-to-end objection (or any other) to NAT ?

I also don't see that IPV6 reduces my need for NAT.
For instance, my ISP will probably still give me only one IP address 
that I'll want to share with my home network.

Re: NAT for IPv6

[Henrik Nordstrom]

On Fri, 21 Nov 2003, Don Cohen wrote:

> I also don't see that IPV6 reduces my need for NAT.
> For instance, my ISP will probably still give me only one IP address
> that I'll want to share with my home network.

Not if they follow the recommendations on IPv6 address assignment.

[RFC3177]
3. Address Delegation Recommendations


   The IESG and the IAB recommend the allocations for the boundary
   between the public and the private topology to follow those general
   rules:
   
      -  /48 in the general case, except for very large subscribers.
      -  /64 when it is known that one and only one subnet is needed by
         design.
      -  /128 when it is absolutely known that one and only one device
         is connecting.

   In particular, we recommend:

      -  Home network subscribers, connecting through on-demand or
         always-on connections should receive a /48.
      -  Small and large enterprises should receive a /48.
      -  Very large subscribers could receive a /47 or slightly shorter
         prefix, or multiple /48's.
      -  Mobile networks, such as vehicles or mobile phones with an
         additional network interface (such as bluetooth or 802.11b)
         should receive a static /64 prefix to allow the connection of
         multiple devices through one subnet.
      -  A single PC, with no additional need to subnet, dialing-up from
         a hotel room may receive its /128 IPv6 address for a PPP style
         connection as part of a /64 prefix.
[END QUOTE]

The RFC contains some quite interesting discussions which defenitely is 
worth reading when consitering IPv6 addressing.

But sure, there will probably initially be some ISPs who assigns /128
prefixes to their users for marketing reasons so they can charge more for
a connection where you can connect more than one equipment. If you happens
to get such ISP or other similar situation then I would recommend the use
of SOCKS to share access to the public IP (including incoming sessions)
among your stations without violating the end-to-end property of IP.

Regards
Henrik

Re: NAT for IPv6

[Sven-Haegar Koch]

On Sat, 22 Nov 2003, Henrik Nordstrom wrote:

> On Fri, 21 Nov 2003, Don Cohen wrote:
>
> > I also don't see that IPV6 reduces my need for NAT.
> > For instance, my ISP will probably still give me only one IP address
> > that I'll want to share with my home network.
>
> Not if they follow the recommendations on IPv6 address assignment.
>
> [RFC3177]
> 3. Address Delegation Recommendations
[snip]
>       -  /128 when it is absolutely known that one and only one device
>          is connecting.

"This is a single user home dsl, you may only connect one computer and no
router - if you want something more, there is our business/professional
contract, with only 3 times the price" :/ - absolutely normal with most
cheap enduser-dsl.
currently there is no problem with this and nat, even if it's not
officially allowed, it is not enforced - but what then with v6?

I don't see the big dsl-players to change that anytime soon.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: NAT for IPv6

[Willy Tarreau]

On Sun, Nov 23, 2003 at 09:05:51AM +0100, Sven-Haegar Koch wrote:
> >       -  /128 when it is absolutely known that one and only one device
> >          is connecting.
> 
> "This is a single user home dsl, you may only connect one computer and no
> router - if you want something more, there is our business/professional
> contract, with only 3 times the price" :/ - absolutely normal with most
> cheap enduser-dsl.
> currently there is no problem with this and nat, even if it's not
> officially allowed, it is not enforced - but what then with v6?
> 
> I don't see the big dsl-players to change that anytime soon.

Then change your provider. Mine already offers me a /48 for free with even
the lowest home user contract. If a provider wants to enforce a /128, then
he may also try to detect multiple hosts by analysing TCP sequence numbers.
Right now, providers are clearly aware that many of their customers have
more than one host (father gives the old P3 to the son and buys a new P4),
and they often have no problem with that. What they don't want, is you to
provide access to your neighbour for free. But with all the bandwidth-hungry
people over there, it becomes less common that it once was. Would you share
your SSH entry point with a neighbour interested in P2P ?

Cheers,
Willy

Re: NAT for IPv6

[Don Cohen]

I didn't really want to discuss what ISPs were going to offer.  
I'll even refrain, with great effort, from discussing RFC3177.

My real question is what reason anyone would have for objecting to
NAT.  So far I don't understand the end-to-end argument.  As I read
the RFCs the main argument is that places where there is a choice in
routing should not maintain connection state because the routing might
change.  If a connection between points A and B might and might not be
forwarded through point C then I agree that point C should not be
doing NAT on those packets.  The same applies to any other sort of
connection tracking.  However, I think a good definition of a firewall
is that it's a machine through which certain traffic MUST pass, and
for such a machine to do NAT on that traffic still seems reasonable.

Please enlighten me.

Re: NAT for IPv6

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Fri, Nov 21, 2003 at 11:05:13PM -0800, Don Cohen wrote:

> I also don't see that IPV6 reduces my need for NAT.
> For instance, my ISP will probably still give me only one IP address 
> that I'll want to share with my home network.

That is actually violating the address allocation guidelines of the
RIR's, IIRC.

Unless there is only a single segment on the other side, you should
receive a /48.  If there is only a single segment, a /64.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

NAT for IPv6

[Phillips, Matthew USA]

Is it possible to do strictly v6 to v6 NAT'ing, not 6to4 tunneling? I know I'm going to get the reponse that we don't need NAT for IPv6 due to the increased address space, but NAT also provides the added security benifit of network topology hiding. So, my question is, is it possible to port over the NAT functionality from iptables to ip6tables and also, has it been done already? Thanks for any input.

Matt

Re: NAT for IPv6

[Cedric Blancher]

Le jeu 11/03/2004 à 00:58, Phillips, Matthew USA a écrit :
> Is it possible to do strictly v6 to v6 NAT'ing

Yes, one can do this.

> So, my question is, is it possible to port over the NAT functionality
> from iptables to ip6tables and also, has it been done already? Thanks
> for any input.

It's not planed for Netfilter, and afaik won't be. But I guess one can
implement this. But, conntrack for IPv6 will be necessary first, and
it's not done yet either.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!