nf_conntrack & NAT

nf_conntrack & NAT

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 216 bytes --]

Hello,

As we have now working nfnetlink in nf_conntrack (thanks!) I'm wonder if 
there any plans for porting IPv4 NAT to nf_conntrack and adding NAT 
support for IPv6?

Best regards,


 			Krzysztof Olędzki

Re: nf_conntrack & NAT

[Yasuyuki KOZAKAI]

Hi,

From: Krzysztof Oledzki <olenf@ans.pl>
Date: Wed, 23 Nov 2005 12:30:07 +0100 (CET)

> Hello,
> 
> As we have now working nfnetlink in nf_conntrack (thanks!) I'm wonder if 
> there any plans for porting IPv4 NAT to nf_conntrack

Of cause we have. But

>                                                      and adding NAT 
> support for IPv6?

Never ever. You can learn why people don't want to do it from many sources.
For example, You can use many addresses in IPv6 world. And I don't want people
get troubles due to NAT traversal issues in IPv6 world.

-- Yasuyuki Kozakai

Re: nf_conntrack & NAT

[Herve Eychenne]

On Wed, Nov 23, 2005 at 09:25:47PM +0900, Yasuyuki KOZAKAI wrote:

 Hi,

> >                                                      and adding NAT 
> > support for IPv6?

> Never ever. You can learn why people don't want to do it from many sources.
> For example, You can use many addresses in IPv6 world. And I don't want people
> get troubles due to NAT traversal issues in IPv6 world.

And what if you want your firewall to transparently redirect some traffic
to another host, for example?

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: nf_conntrack & NAT

[Jan Kasprzak]

Herve Eychenne wrote:
: On Wed, Nov 23, 2005 at 09:25:47PM +0900, Yasuyuki KOZAKAI wrote:
: 
:  Hi,
: 
: > >                                                      and adding NAT 
: > > support for IPv6?
: 
: > Never ever. You can learn why people don't want to do it from many sources.
: > For example, You can use many addresses in IPv6 world. And I don't want people
: > get troubles due to NAT traversal issues in IPv6 world.
: 
: And what if you want your firewall to transparently redirect some traffic
: to another host, for example?
: 
	... or IPVS-based clusters. NAT functionality is definitely
wanted (even though full NAT in the IPv6 world is evil :-).

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> Specs are a basis for _talking_about_ things. But they are _not_ a basis <
> for implementing software.                              --Linus Torvalds <

Re: nf_conntrack & NAT

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 804 bytes --]



On Wed, 23 Nov 2005, Yasuyuki KOZAKAI wrote:

>
> Hi,
>
> From: Krzysztof Oledzki <olenf@ans.pl>
> Date: Wed, 23 Nov 2005 12:30:07 +0100 (CET)
>
>> Hello,
>>
>> As we have now working nfnetlink in nf_conntrack (thanks!) I'm wonder if
>> there any plans for porting IPv4 NAT to nf_conntrack
>
> Of cause we have. But

Where can I find it?

>>                                                      and adding NAT
>> support for IPv6?
>
> Never ever. You can learn why people don't want to do it from many sources.
> For example, You can use many addresses in IPv6 world. And I don't want people
> get troubles due to NAT traversal issues in IPv6 world.

Oh. So how we are going to make transparent proxy, port redirects, etc 
possible?

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack & NAT

[Yasuyuki KOZAKAI]

From: Krzysztof Oledzki <olenf@ans.pl>
Date: Wed, 23 Nov 2005 14:44:01 +0100 (CET)

> On Wed, 23 Nov 2005, Yasuyuki KOZAKAI wrote:
> 
> >
> > Hi,
> >
> > From: Krzysztof Oledzki <olenf@ans.pl>
> > Date: Wed, 23 Nov 2005 12:30:07 +0100 (CET)
> >
> >> Hello,
> >>
> >> As we have now working nfnetlink in nf_conntrack (thanks!) I'm wonder if
> >> there any plans for porting IPv4 NAT to nf_conntrack
> >
> > Of cause we have. But
> 
> Where can I find it?

We have 'plan', but no code yet AFAIK, sorry :)

> >>                                                      and adding NAT
> >> support for IPv6?
> >
> > Never ever. You can learn why people don't want to do it from many sources.
> > For example, You can use many addresses in IPv6 world. And I don't want people
> > get troubles due to NAT traversal issues in IPv6 world.
> 
> Oh. So how we are going to make transparent proxy, port redirects, etc 
> possible?

At first, I will not implement IPv6 NAT at least, but I don't know
what other people think.

And about transparent proxy, port redirects, load balancer, and so on,
indeed currently we seems that we don't have smarter and de facto standard
solutions.

I wonder why they haven't come up yet, but anyway, I believe people can
develop smarter solutions than copied and pasted IPv4 NAT (It's possible that
just I don't know them and someone might have already developed them).
I think it's still early to give up on.

-- Yasuyuki Kozakai

Re: nf_conntrack & NAT

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> From: Krzysztof Oledzki <olenf@ans.pl>
> Date: Wed, 23 Nov 2005 14:44:01 +0100 (CET)
> 
>>Oh. So how we are going to make transparent proxy, port redirects, etc 
>>possible?
> 
> 
> At first, I will not implement IPv6 NAT at least, but I don't know
> what other people think.
> 
> And about transparent proxy, port redirects, load balancer, and so on,
> indeed currently we seems that we don't have smarter and de facto standard
> solutions.
> 
> I wonder why they haven't come up yet, but anyway, I believe people can
> develop smarter solutions than copied and pasted IPv4 NAT (It's possible that
> just I don't know them and someone might have already developed them).
> I think it's still early to give up on.

Transparent proxying can be done with tproxy without NAT (I'm not
sure how far along their new patches are), the idea is to exchange
the dst_entry of the skb instead of rewriting packets.

Re: nf_conntrack & NAT

[Balazs Scheidler]

On Sun, 2005-11-27 at 00:52 +0100, Patrick McHardy wrote:
> Yasuyuki KOZAKAI wrote:
> > From: Krzysztof Oledzki <olenf@ans.pl>
> > Date: Wed, 23 Nov 2005 14:44:01 +0100 (CET)
> > 
> >>Oh. So how we are going to make transparent proxy, port redirects, etc 
> >>possible?
> > 
> > 
> > At first, I will not implement IPv6 NAT at least, but I don't know
> > what other people think.
> > 
> > And about transparent proxy, port redirects, load balancer, and so on,
> > indeed currently we seems that we don't have smarter and de facto standard
> > solutions.
> > 
> > I wonder why they haven't come up yet, but anyway, I believe people can
> > develop smarter solutions than copied and pasted IPv4 NAT (It's possible that
> > just I don't know them and someone might have already developed them).
> > I think it's still early to give up on.
> 
> Transparent proxying can be done with tproxy without NAT (I'm not
> sure how far along their new patches are), the idea is to exchange
> the dst_entry of the skb instead of rewriting packets.

Far from being complete, but I've tested all the necessary functions
individually for IPv4/TCP (established connection + port redirection,
the latter seemed a show-stopper back at the workshop, but can be
solved)

-- 
Bazsi

Re: nf_conntrack & NAT

[Harald Welte]

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

On Wed, Nov 23, 2005 at 02:24:19PM +0100, Jan Kasprzak wrote:
> Herve Eychenne wrote:
> : On Wed, Nov 23, 2005 at 09:25:47PM +0900, Yasuyuki KOZAKAI wrote:
> : 
> :  Hi,
> : 
> : > >                                                      and adding NAT 
> : > > support for IPv6?
> : 
> : > Never ever. You can learn why people don't want to do it from many sources.
> : > For example, You can use many addresses in IPv6 world. And I don't want people
> : > get troubles due to NAT traversal issues in IPv6 world.
> : 
> : And what if you want your firewall to transparently redirect some traffic
> : to another host, for example?
> : 
> 	... or IPVS-based clusters. NAT functionality is definitely
> wanted (even though full NAT in the IPv6 world is evil :-).

guys, we have to differentiate here.

I often stated "nf_conntrack based ipv6 nat only over my dead body".
This refers to something similar to the current IPv4 NAT code as a
stateful, fully symmetric, port overloading NAPT attached to the
connection tracking code.

for stuff like redirecting traffic, all you really need is stateless
rewriting of the destination address.  If people want that, the entire
implementation fits in a single ip6tables target.  no relation to
nf_conntrack at all.

also, IPVS doesn't need any ip_conntrack/iptable_nat today, why would it
need that for ipv6?
-- 
- Harald Welte <laforge@netfilter.org>                 http://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: nf_conntrack & NAT

[Herve Eychenne]

On Tue, Dec 06, 2005 at 09:13:21PM +0530, Harald Welte wrote:

> On Wed, Nov 23, 2005 at 02:24:19PM +0100, Jan Kasprzak wrote:

> > : > > support for IPv6?

> > : > Never ever. You can learn why people don't want to do it from many sources.
> > : > For example, You can use many addresses in IPv6 world. And I don't want people
> > : > get troubles due to NAT traversal issues in IPv6 world.

> > : And what if you want your firewall to transparently redirect some traffic
> > : to another host, for example?

> > 	... or IPVS-based clusters. NAT functionality is definitely
> > wanted (even though full NAT in the IPv6 world is evil :-).

> guys, we have to differentiate here.

> I often stated "nf_conntrack based ipv6 nat only over my dead body".
> This refers to something similar to the current IPv4 NAT code as a
> stateful, fully symmetric, port overloading NAPT attached to the
> connection tracking code.

> for stuff like redirecting traffic, all you really need is stateless
> rewriting of the destination address.  If people want that, the entire
> implementation fits in a single ip6tables target.  no relation to
> nf_conntrack at all.

Stateless?  And what if you want the response (of the packets which have
been redirected) to come back with their initial address, as if they
had not been redirected? (if the client shouldn't know that, if this
should be transparent to him)
This is also known as DNAT, for which the state has be stored, right?

So, in one word: if we definitely need DNAT with IPv4 today, why
wouldn't we need DNAT with IPv6?

> also, IPVS doesn't need any ip_conntrack/iptable_nat today,

I don't know IPVS implementation, but maybe the IPVS-NAT method could
theorically share some code with the current NAT code... (they both
seem to handle the same kind of state table, even if at least the hashing
algorithm could probably be different, I guess)

> why would it need that for ipv6?

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: nf_conntrack & NAT

[Patrick Schaaf]

> > Stateless?  And what if you want the response (of the packets which have
> > been redirected) to come back with their initial address, as if they
> > had not been redirected? (if the client shouldn't know that, if this
> > should be transparent to him)
> 
> then you need a static snat target that does this for all reply packets.

How do you expect to match those reply targets?

Be aware that REDIRECT does not mean REDIRECT-always-for-the-same
source-and-destination-pair. Such thinking would be too restrictive.

For example, I use ipset bitmaps to determine, at conntrack-NEW-time,
whether some connection should be REDIRECTed, or not. This decision,
once made, should stay stable for the same connection, even if the
ipset bitmap is modified wrt to another new connection between the
same partners.

So I at least need conntracking, and some way to _mark_ connections,
if the connection does not store a NAT decision itself. Or my usage
won't be supported for IPv6. (not a problem at the moment, but who
knows)

> stateful IPv6 NAT only over my dead body.  Do you know that NAT is the
> single most destructive way that ever happened to todays internet?  That
> it is the number one reason why VoIP doesn't really take off as much as
> it could?  The number one reason for various non-deterministic breakage
> all over the place? 

All known. All completely nonapplicable for REDIRECT.

best regards
  Patrick

Re: nf_conntrack & NAT

[Harald Welte]

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

On Tue, Dec 06, 2005 at 06:31:35PM +0100, Herve Eychenne wrote:
> > for stuff like redirecting traffic, all you really need is stateless
> > rewriting of the destination address.  If people want that, the entire
> > implementation fits in a single ip6tables target.  no relation to
> > nf_conntrack at all.
> 
> Stateless?  And what if you want the response (of the packets which have
> been redirected) to come back with their initial address, as if they
> had not been redirected? (if the client shouldn't know that, if this
> should be transparent to him)

then you need a static snat target that does this for all reply packets.

> This is also known as DNAT, for which the state has be stored, right?

you don't really need state unless you want to do stuff like dynamically
changing port numbers, etc.

> So, in one word: if we definitely need DNAT with IPv4 today, why
> wouldn't we need DNAT with IPv6?

stateful IPv6 NAT only over my dead body.  Do you know that NAT is the
single most destructive way that ever happened to todays internet?  That
it is the number one reason why VoIP doesn't really take off as much as
it could?  The number one reason for various non-deterministic breakage
all over the place? 

I've participated in the IETF BEHAVE group discussions, and there was
concensus that any BEHAVE compliant NAT must not do NAT for ipv6.
 
> > also, IPVS doesn't need any ip_conntrack/iptable_nat today,
> 
> I don't know IPVS implementation, but maybe the IPVS-NAT method could
> theorically share some code with the current NAT code... (they both
> seem to handle the same kind of state table, even if at least the hashing
> algorithm could probably be different, I guess)

*sigh*.  IPVS doesn't use ip_conntrack, so they won't be using
nf_conntrack.  Also, it's their project and their decision.

-- 
- Harald Welte <laforge@netfilter.org>                 http://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: nf_conntrack & NAT

[Patrick Schaaf]

Hi Harald,

[SNIP]
> If we later need something different for IPv6, then let's do that at
> this later point.

Hey! That's absolutely fine with me. I don't care about v6 at all,
at the moment, and in the next few years.

But I couldn't let stand the opinion that stateless NAT would
be sufficient for what is now done with REDIRECT and v4.

BTW, my special application might well be the normal case for
a lot of nifty "captive portal" setups, e.g. at WLAN hotspots.

best regards
  Patrick

Re: nf_conntrack & NAT

[Jozsef Kadlecsik]

On Tue, 6 Dec 2005, Herve Eychenne wrote:

> On Tue, Dec 06, 2005 at 09:13:21PM +0530, Harald Welte wrote:
>
> > for stuff like redirecting traffic, all you really need is stateless
> > rewriting of the destination address.  If people want that, the entire
> > implementation fits in a single ip6tables target.  no relation to
> > nf_conntrack at all.
>
> Stateless?  And what if you want the response (of the packets which have
> been redirected) to come back with their initial address, as if they
> had not been redirected? (if the client shouldn't know that, if this
> should be transparent to him)
> This is also known as DNAT, for which the state has be stored, right?
>
> So, in one word: if we definitely need DNAT with IPv4 today, why
> wouldn't we need DNAT with IPv6?

IPv6 is not just IPv4 with a larger address space. Definitely there is no
need for DNAT in order to make a server with private address available.
But I can imagine for example to replace the "need" for DNAT with anycast
in IPv6 for load balancing.

Old hacks and workarounds should not be reimplemented blindly.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Herve Eychenne]

On Wed, Dec 07, 2005 at 12:35:17PM +0530, Harald Welte wrote:

> On Tue, Dec 06, 2005 at 06:31:35PM +0100, Herve Eychenne wrote:
> > > for stuff like redirecting traffic, all you really need is stateless
> > > rewriting of the destination address.  If people want that, the entire
> > > implementation fits in a single ip6tables target.  no relation to
> > > nf_conntrack at all.
> > 
> > Stateless?  And what if you want the response (of the packets which have
> > been redirected) to come back with their initial address, as if they
> > had not been redirected? (if the client shouldn't know that, if this
> > should be transparent to him)

> then you need a static snat target that does this for all reply packets.

Ok, let's say that some packets originally destined to host A are
redirected to host B (dst addr changed).
Of course, regular packets coming from B should not have their
src addr systematically changed to A...
So how do you know that some packets coming back from host B are part of
a connection that was originally destined to host A (their src addr
should be changed to A again for transparency) without storing state?

> > This is also known as DNAT, for which the state has be stored, right?

> you don't really need state unless you want to do stuff like dynamically
> changing port numbers, etc.

Or dst addresses, yes.  And that's what is needed here.

> > So, in one word: if we definitely need DNAT with IPv4 today, why
> > wouldn't we need DNAT with IPv6?

> stateful IPv6 NAT only over my dead body.  Do you know that NAT is the
> single most destructive way that ever happened to todays internet?  That
> it is the number one reason why VoIP doesn't really take off as much as
> it could?  The number one reason for various non-deterministic breakage
> all over the place? 

I know all of this.

> I've participated in the IETF BEHAVE group discussions, and there was
> concensus that any BEHAVE compliant NAT must not do NAT for ipv6.

I understand that core network developpers have been bitten more than once
by NAT issues, and that they've become so allergic to it that the
evocation of this simple word can make them cry at night.

But even if massive use of NAT should definitely be considered
harmful and should not be encouraged, some uses of NAT/PAT can still be
considered legitimate even with IPv6 as some specific technical needs are
still there.
Like a french expression says, I just think we should not throw the baby
with the (unclean) water of his bath.

Anyway, until IPv6 is widely used elsewhere than in Asia, there is no
real hurry for retarded occidentals like us. ;-)

> > > also, IPVS doesn't need any ip_conntrack/iptable_nat today,
> > 
> > I don't know IPVS implementation, but maybe the IPVS-NAT method could
> > theorically share some code with the current NAT code... (they both
> > seem to handle the same kind of state table, even if at least the hashing
> > algorithm could probably be different, I guess)

> *sigh*.  IPVS doesn't use ip_conntrack,

I was only saying that maybe it could have, from a technical point of
view (I always praise code factorization).  I was not particularly
encouraging it here though.

> so they won't be using nf_conntrack. Also, it's their project and their decision.

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: nf_conntrack & NAT

[Harald Welte]

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

On Wed, Dec 07, 2005 at 08:00:39AM +0100, Patrick Schaaf wrote:
> For example, I use ipset bitmaps to determine, at conntrack-NEW-time,
> whether some connection should be REDIRECTed, or not. This decision,
> once made, should stay stable for the same connection, even if the
> ipset bitmap is modified wrt to another new connection between the
> same partners.

Patrick, whatever kind of special-case applications you might have, I
honestly don't care at this point.

The fundamental issue at this time is to get nf_conntrack
feature-complete with what ip_conntrack offers.  This allows us to get
rid of ip_conntrack and therby remove lots of duplicate code that was
only meant as an intermediate solution.

The other fundamental issue is that we don't want to extend the current
full-blown ip_nat/iptable_nat code to offer the same functionality for
IPv6.

So that's why nf_conntrack based stateful nat will be restricted to
IPv4.

If we later need something different for IPv6, then let's do that at
this later point.

-- 
- Harald Welte <laforge@netfilter.org>                 http://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: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Herve Eychenne]

On Wed, Dec 07, 2005 at 12:22:22PM +0100, Jozsef Kadlecsik wrote:

> On Tue, 6 Dec 2005, Herve Eychenne wrote:

> > On Tue, Dec 06, 2005 at 09:13:21PM +0530, Harald Welte wrote:
> >
> > > for stuff like redirecting traffic, all you really need is stateless
> > > rewriting of the destination address.  If people want that, the entire
> > > implementation fits in a single ip6tables target.  no relation to
> > > nf_conntrack at all.
> >
> > Stateless?  And what if you want the response (of the packets which have
> > been redirected) to come back with their initial address, as if they
> > had not been redirected? (if the client shouldn't know that, if this
> > should be transparent to him)
> > This is also known as DNAT, for which the state has be stored, right?
> >
> > So, in one word: if we definitely need DNAT with IPv4 today, why
> > wouldn't we need DNAT with IPv6?

> IPv6 is not just IPv4 with a larger address space. Definitely there is no
> need for DNAT in order to make a server with private address available.
> But I can imagine for example to replace the "need" for DNAT with anycast
> in IPv6 for load balancing.

I don't want to use DNAT for load balancing.  I want to use DNAT (and
I'm using it just now with IPv4) to redirect traffic destined to a
certain IP/port to another IP (private or not) in the most transparent
way. There are plenty of scenari where I'm willing to do that.



For those who need practical examples (others can stop here) that I'm
regularly facing myself, here it is.

Then MX of domain points on host A, and I want to redirect SMTP traffic
to host B (also in my network) in the most atomic way.
DNS propagation can be slow (caching), and user proxying is too slow
(and not transparent).
If there are miraculous mecanisms in IPv6 which enable to achieve that
redirection as atomically and quickly that DNAT, please let me know.

And that's only one example.
Another? Ok... ;-)

Lets say I have a DNS entry that points to a certain IP address. But
I have a problem (configuration, whatever) with http server on this host,
and I want the web traffic destined to this IP on port 80/tcp (but not
other services!) to be handled by a given server (IP2), which already
handles several virtualhosts.
So I use:  -d IP1 -p tcp --dport 80 -j DNAT --to IP2:80

And on top of that, imagine that it is not convenient (configuration
issues, server not powerful enough, restrictive SSL certificate, whatever)
to handle https traffic in this host (IP2) as well...
So I would redirect https traffice on server 3 (IP3) instead:
-d IP1 -p tcp --dport 443 -j DNAT --to IP3:443

Once everything is OK, I can probably change DNS entries accordingly and
certainly get rid of some DNAT rules... (even if I don't see well how I
could transparently handle HTTP traffic on one server, and HTTPS on
another, anyway...)
But the DNAT rule are definitely useful in the meantime, unless I'm
showed something that would achieve exactly the same in a more IPv6 way...

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Jozsef Kadlecsik]

On Wed, 7 Dec 2005, Herve Eychenne wrote:

> I don't want to use DNAT for load balancing.  I want to use DNAT (and
> I'm using it just now with IPv4) to redirect traffic destined to a
> certain IP/port to another IP (private or not) in the most transparent
> way. There are plenty of scenari where I'm willing to do that.
>
> For those who need practical examples (others can stop here) that I'm
> regularly facing myself, here it is.
>
> Then MX of domain points on host A, and I want to redirect SMTP traffic
> to host B (also in my network) in the most atomic way.
> DNS propagation can be slow (caching), and user proxying is too slow
> (and not transparent).
> If there are miraculous mecanisms in IPv6 which enable to achieve that
> redirection as atomically and quickly that DNAT, please let me know.

Yes, use as many IP addresses as you want :-):

Host A:
	addressA0: maintenance
	addressA1: az advertised SMTP server
	addressA2: az advertised HTTP server
	...
Host B:
	addressB0: maintenance
	addressB1: az advertised SMTP server
	addressB2: az advertised HTTP server
	...

If you want to "replace" A as SMTP server by server B, just assign
addressA1 to server B. That's it. No NAT required at all and it
is practically atomic.

(Assumed the same network as you wrote.)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Herve Eychenne]

On Wed, Dec 07, 2005 at 04:09:25PM +0100, Jozsef Kadlecsik wrote:

> On Wed, 7 Dec 2005, Herve Eychenne wrote:

> > I don't want to use DNAT for load balancing.  I want to use DNAT (and
> > I'm using it just now with IPv4) to redirect traffic destined to a
> > certain IP/port to another IP (private or not) in the most transparent
> > way. There are plenty of scenari where I'm willing to do that.
> >
> > For those who need practical examples (others can stop here) that I'm
> > regularly facing myself, here it is.
> >
> > Then MX of domain points on host A, and I want to redirect SMTP traffic
> > to host B (also in my network) in the most atomic way.
> > DNS propagation can be slow (caching), and user proxying is too slow
> > (and not transparent).
> > If there are miraculous mecanisms in IPv6 which enable to achieve that
> > redirection as atomically and quickly that DNAT, please let me know.

> Yes, use as many IP addresses as you want :-):

> Host A:
> addressA0: maintenance
> addressA1: az advertised SMTP server
> addressA2: az advertised HTTP server
> ...
> Host B:
> addressB0: maintenance
> addressB1: az advertised SMTP server
> addressB2: az advertised HTTP server
> ...

> If you want to "replace" A as SMTP server by server B, just assign
> addressA1 to server B. That's it. No NAT required at all and it
> is practically atomic.

> (Assumed the same network as you wrote.)

So each time you add a service on a host, you should assign a new IP to it
(and create the respective DNS name for this IP/service couple!), just in
case you may have to redirect its traffic one day? (even if temporary)

Oh my... If IPv6 (without DNAT) really implies that, I can still live with
IPv4 for a (very) long time!

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Patrick Schaaf]

> So each time you add a service on a host, you should assign a new IP to it
> (and create the respective DNS name for this IP/service couple!), just in
> case you may have to redirect its traffic one day? (even if temporary)

This has proven to be a very valuable strategy, at work, even for normal
IPv4 operation. Saves headaches every time we want to migrate something.
I can warmly recommend this practise.

best regards
  Patrick

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Harald Welte]

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

On Thu, Dec 08, 2005 at 12:56:32PM +0100, Patrick Schaaf wrote:
> > So each time you add a service on a host, you should assign a new IP to it
> > (and create the respective DNS name for this IP/service couple!), just in
> > case you may have to redirect its traffic one day? (even if temporary)
> 
> This has proven to be a very valuable strategy, at work, even for normal
> IPv4 operation. Saves headaches every time we want to migrate something.
> I can warmly recommend this practise.

I totally agree.  Esp. with IPv6 there is no reason to do otherwise...
A /64 for every physical network segment, guess people still need to get
used to it.

-- 
- Harald Welte <laforge@netfilter.org>                 http://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: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Harald Welte]

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

On Thu, Dec 08, 2005 at 12:56:32PM +0100, Patrick Schaaf wrote:
> > So each time you add a service on a host, you should assign a new IP to it
> > (and create the respective DNS name for this IP/service couple!), just in
> > case you may have to redirect its traffic one day? (even if temporary)
> 
> This has proven to be a very valuable strategy, at work, even for normal
> IPv4 operation. Saves headaches every time we want to migrate something.
> I can warmly recommend this practise.

oh btw, this also solves the usual ssl certificate problem, where you
for example tell people to use smtp/tls or imap/tls or whatever to
"smtp.foo.org" which might be a cname, and thus the certificate name
doesn't always match the 'dn' of the cert.

A very clean solution, indeed.

-- 
- Harald Welte <laforge@netfilter.org>                 http://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: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1055 bytes --]



On Fri, 9 Dec 2005, Harald Welte wrote:

> On Thu, Dec 08, 2005 at 12:56:32PM +0100, Patrick Schaaf wrote:
>>> So each time you add a service on a host, you should assign a new IP to it
>>> (and create the respective DNS name for this IP/service couple!), just in
>>> case you may have to redirect its traffic one day? (even if temporary)
>>
>> This has proven to be a very valuable strategy, at work, even for normal
>> IPv4 operation. Saves headaches every time we want to migrate something.
>> I can warmly recommend this practise.
>
> I totally agree.  Esp. with IPv6 there is no reason to do otherwise...
> A /64 for every physical network segment, guess people still need to get
> used to it.

But if you need to move IP betwen machines then you need one ip for each 
service, probably with /32 mask for IPv4 and /64 for IPv6. There is no 
problem when using private addresses and IPv4, should be no problem for 
IPv6 but there is no way to do it that way with public IPv4 addressess.

Best regards,

 				Krzysztof Olędzki

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Patrick Schaaf]

> [...] but there is no way to do it that way with public IPv4 addressess.

For all I know, separation of services has always been a valid use
of IPv4 address space, so I really don't buy your 'but there is no way'.

We are doing it. Who will sue us, on which basis? We are a RIPE member
and LIR, so pointing to RIPE policy will be best to prove your point.
Maybe I'm wrong. I'm not involved in the LIR part of the business.
But I don't think so.

best regards
  Patrick

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Balazs Scheidler]

[ trimmed Cc line ]

On Fri, 2005-12-09 at 10:27 +0530, Harald Welte wrote:
> On Thu, Dec 08, 2005 at 12:56:32PM +0100, Patrick Schaaf wrote:
> > > So each time you add a service on a host, you should assign a new IP to it
> > > (and create the respective DNS name for this IP/service couple!), just in
> > > case you may have to redirect its traffic one day? (even if temporary)
> > 
> > This has proven to be a very valuable strategy, at work, even for normal
> > IPv4 operation. Saves headaches every time we want to migrate something.
> > I can warmly recommend this practise.
> 
> oh btw, this also solves the usual ssl certificate problem, where you
> for example tell people to use smtp/tls or imap/tls or whatever to
> "smtp.foo.org" which might be a cname, and thus the certificate name
> doesn't always match the 'dn' of the cert.

Even though this is usually a question of paying for several
certificates and not being unable to put different certificates to
different ports.

-- 
Bazsi

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Alexander Samad]

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

On Mon, Dec 12, 2005 at 09:42:33PM +0100, Balazs Scheidler wrote:
> [ trimmed Cc line ]
> 
> On Fri, 2005-12-09 at 10:27 +0530, Harald Welte wrote:
> > On Thu, Dec 08, 2005 at 12:56:32PM +0100, Patrick Schaaf wrote:
> > > > So each time you add a service on a host, you should assign a new IP to it
> > > > (and create the respective DNS name for this IP/service couple!), just in
> > > > case you may have to redirect its traffic one day? (even if temporary)
> > > 
> > > This has proven to be a very valuable strategy, at work, even for normal
> > > IPv4 operation. Saves headaches every time we want to migrate something.
> > > I can warmly recommend this practise.
> > 
> > oh btw, this also solves the usual ssl certificate problem, where you
> > for example tell people to use smtp/tls or imap/tls or whatever to
> > "smtp.foo.org" which might be a cname, and thus the certificate name
> > doesn't always match the 'dn' of the cert.
> 
> Even though this is usually a question of paying for several
> certificates and not being unable to put different certificates to
> different ports.

Has the issue of trying to load balance serveral machine behind a nat
box been brought up for ipv6, if DNAT (and SNAT) are not available for
ipv6 how are you going to hid a farm of servers behind a single (or
multiple addresses), DNS round robin doesn't work because it doesn't
take into account weather the ip is active or not ?


> 
> -- 
> Bazsi
> 
> 
> 

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

Re: (D)NAT with IPv6 (was "nf_conntrack & NAT")

[Balazs Scheidler]

On Tue, 2005-12-13 at 09:56 +1100, Alexander Samad wrote:
> Has the issue of trying to load balance serveral machine behind a nat
> box been brought up for ipv6, if DNAT (and SNAT) are not available for
> ipv6 how are you going to hid a farm of servers behind a single (or
> multiple addresses), DNS round robin doesn't work because it doesn't
> take into account weather the ip is active or not ?

You could do something similar with policy routing, e.g. mark the
connections based on your load-balancing decision and have routing to
direct packets based on this mark to the appropriate boxes, e.g. select
next-hop based on connection mark.

Now it is only a question of the servers whether they are willing to
serve connections originally destined to a different IP address. (this
requires something like tproxy to work).

Of course the above is not optimal as it is not transparent to the
servers involved, but can be solved nevertheless.

Alternatively you can do it from userspace with some kernel backing to
avoid copying data to userspace (e.g. establish two IPv6 connections the
way you like and ask a kernel function to copy data on the two separate
sockets). It is not as fast as forwarding but I doubt it would be much
slower than the current NAT framework.

-- 
Bazsi