Subject: RE: [midcom] accept R3a1 & R3a2

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 2 Oct 2001 14:40:22 +0100

I want to stress that we need a requirement such as:
The Midcom protocol MUST work through NATs.
Mechanisms such as the informant method will not work through NATs so we
should not forget this requirement. 
In the case of  VoIP services provided by service providers (i.e. Telephony
Service Providers), 
the Midcom agent might be behind a NAT .

Cedric

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 4:12 PM
To: Scott Brim; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2

At 09:40 AM 9/26/01 -0400, Scott Brim wrote:
>Would 'must operate through a NAT' be a pathological case?

The presence of more than one NAT is not that uncommon, 
unfortunately.  I've personally never heard of multiple 
middleboxes sharing a single address, other than failover
scenarios or clustering, where routing is handled at a 
lower layer.  Are there such things?  As I said, it is not
my impression that much thought has been given to what
this requirement actually means for protocol design.  I
think we're covered.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Scott Brim <[email-masked]>
Date: Wed, 10 Oct 2001 10:15:52 -0400

On Tue, Oct 02, 2001 02:40:22PM +0100, Cedric Aoun allegedly wrote:
> I want to stress that we need a requirement such as: The Midcom
> protocol MUST work through NATs.  Mechanisms such as the informant
> method will not work through NATs so we should not forget this
> requirement.  In the case of  VoIP services provided by service
> providers (i.e. Telephony Service Providers), the Midcom agent might
> be behind a NAT .

Cedric, I think you're confused.  Agents are only relevant in terms of
the middleboxes they can control.  

In the case above, where an agent is "behind" a NAT, does it control
that NAT?  If so there is no problem, because they share an address
space.  

If you're saying there is a client on one side of a NAT, and some midcom
agent on the other side, and the agent does NOT control the NAT, then
the agent is irrelevant and you can take it out of your picture -- what
you have is the current situation, with no agent at all.  (Midcom agents
are distinct from application helpers.)

In a situation with a simple network and no scope for a separate agent
device, e.g. a home network, you provide a software "shim" to match the
application.  That bit of software has application-specific
intelligence, and is either a simple midcom agent to control the NAT or
something that speaks one of the short-term protocol approaches people
are discussing now.

So I don't think your objection has merit.

..Scott