Subject: RE: v6 host load balancing

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Mar 2004 12:57:09 +0200 (EET)

On Thu, 4 Mar 2004, Bob Hinden wrote:
> >coz data from the client may be going thru a different device Y, which is
> >being blocked by the fw on that device. fw Y doesn't have the hole
> >to let the traffic go through.
> 
> This won't be caused by the load sharing when the data and control are 
> going to the same destination host.  If the data traffic is going to a 
> different destination host, then it could end up on a different router 
> because of a more specific route or a redirect.  I don't see that load 
> sharing adds to the complexity.

In cases in which this is mostly important, the hosts have a default
route.  Then e.g. SIP data and signalling should go through the same
path.  This is the scenario which fails (in addition to the generic
debug etc. problems which happen when something breaks from one first
hop router to somewhere in the direction of Internet.

Hosts which have more specific routes are set there explicitly,
manually or using the more specific route extension.

I'd still like to remove the "MUST share load" from the document. Of
course, I can see that it's very useful in many scenarios for load
distribution.  But still not a MUST.  What I want to see that the 
implementations implement this feature, so that it's available for use 
for those who need it.  But I want it disabled by default and a MUST 
for a toggle to enable/disable it.   

to implement draft-ietf-ipv6-host-load-sharing-01.txt, otherwise I
don't buy your product".  Does not help in getting stuff like this
deployed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 3 Mar 2004 21:39:29 -0800

> -----Original Message-----
> From: Changming Liu [mailto:[email-masked]]
> Sent: Thursday, March 04, 2004 2:14 PM
> To: Dave Thaler; Changming Liu
> Cc: [email-masked] '
> Subject: RE: v6 host load balancing
> 
> Hi Dave,
> 
> >If the server is telling the client who to use, then the client is
> >connecting out for both the data and the control channels.  If they
> >go out different exit points on the client side, there's no problem
> >since both connections are initiated from the inside, right?
> 
> >Can you elaborate more on what the problematic scenario is?
> 
> Sure. In case of FTP data channel, the data connection was opened by
the
> server by default! This is called active FTP. To get around this
problem,
> RFC1579 Firewall-Friendly FTP, documents a passive open, in this case,
the
> client initiates a connection. For more info, please see RFC 1579.

Yes I'm aware of both modes.  Since you mentioned the server told the
client
what server to use, I assumed you were talking about passive mode, which

is what I was responding to above.

> No matter it is active or passive open, the modem stateful will need
to
> open
> the "hole" by listening to the control channel for "port" and "pasv"
> comamnd.

You lost me here.  Since the passive open has the connection initiated
by the client, there is no need for the firewall around the client to
open a port based on listening to the control channel, right?

> The hole is opened only on the firewall which is dealing the
> control channel. If the data channel goes to another file, apparently
this
> will not work.

I don't see why not.  It's just another outgoing TCP connection.

> FTP is just a classical example of this dynamic port problem that a
> firewall
> needs to deal with. For VoiP apps such H323 and SIP, similar problem
> exists
> as well and even severe. This is because the signalling channel and
media
> channel are totally different and destination are usually completely
> different.
> 
> 
> As a firewall/NAT/IDP company we've been struggling with these issues
all
> the time. It really adds lots of complexity to the system. I just
don't
> want
> to get it worse in IPv6, if not better.
> 
> Hope this makes sense to you.

Not particularly.  I'm still at the same point I was before where 
elaborating on what the exact scenario that fails is would help.

Thanks,
-Dave

> Changming

---

From: Bob Hinden <[email-masked]>
Date: Thu, 04 Mar 2004 00:21:18 -0800

Suresh,

Also, anytime there are multiple routers, the inbound traffic may come back 
to the different router than it went out on.  The same lack of FW state 
problem will occur.  This doesn't have anything to do with load sharing.

Bob

---

From: Suresh Satapati <[email-masked]>
Date: Thu, 4 Mar 2004 00:34:36 -0800 (PST)

> sharing adds to the complexity.

Agreed. I was just trying to clarify Changming's concern.

> problem will occur.  This doesn't have anything to do with load sharing.

Quite possible. But my main concern was why do we insist on a MUST
for the host when there is no convincing reason to do so.

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 3 Mar 2004 23:43:57 -0800 (PST)

Dave,

Lemme give this a try..

> open a port based on listening to the control channel, right?

if there is a fw X on the path to the server, fw X may have to look at
the PASV response and open a hole for the subsequent data traffic
from the client. something like a dynamic (created on-the-fly) outbound
access list.

Hope this helps.

--
Suresh