Subject: [midcom] FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

From: [email-masked]
Date: Mon, 1 Jul 2002 13:13:22 -0500

All,

Sorry for the delay in noticing this.

This I-D was supposed to be announced to the midcom mailing list as well
as the general ietf-announce mailing list, but it wasn't.

Note that this I-D recommends that the midcom protocol requirements be
extended to require support in the midcom protocol for tunnels between
hosts and middleboxes. It's not that the use of tunnels would be
required, but that they would be supported by midcom if used. In our
experience, using tunnels is an extremely attractive alternative to
modifying applications or creating ALGs or agents to allow existing
applications to work correctly with NAT boxes.

The I-D also shows how traditional NAT can be supported in a host as a
tunnel would, and thus accrue the advantages of tunnels: no changes to
applications; no need for ALG or agent. The NAT function in the middlebox
remains unchanged, but a midcom server would need to be added to the
middlebox. But we were planning on doing that anyhow. :-)

Comments welcome and expected.

Jim

---------------------- Forwarded by James Renkel/MW/US/3Com on 07/01/2002
01:02 PM ---------------------------

[email-masked]@cnri.reston.va.us on 06/21/2002 06:37:01 AM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   IETF-Announce: ;
cc:
Subject:  I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

     Title          : NAT and Middlebox Tunnels
     Author(s) : J. Renkel
     Filename  : draft-renkel-middlebox-tunnels-00.txt,.ps
     Pages          : 12
     Date      : 20-Jun-02

This Internet Draft compares Network Address Translation (NAT) and
Realm Specific IP (RSIP) tunnels, and the advantages and
disadvantages of each. It then shows how the advantages can be
combined by implementing NAT as a tunnel in hosts, while
minimizing the disadvantages. Based on the advantages of middlebox
tunnels in general and implementing NAT as a middlebox tunnel in
particular, it then recommends that the Middlebox Communications
architecture protocol (MIDCOM) be amended to support tunnels
between hosts and middleboxes.
This .txt version of this internet draft is identical to the
PostScript version (draft-renkel-middlebox-tunnels-00.ps) except
that the figures from the PostScript version have been deleted.
Please refer to the PostScript version for these figures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-renkel-middlebox-tunnels-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
     "get draft-renkel-middlebox-tunnels-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
     [email-masked].
In the body type:
     "FILE /internet-drafts/draft-renkel-middlebox-tunnels-00.txt".

NOTE:     The mail server at ietf.org can return the document in
     MIME-encoded form by using the "mpack" utility.  To use this
     feature, insert the command "ENCODING mime" before the "FILE"
     command.  To decode the response(s), you will need "munpack" or
     a MIME-compliant mail reader.  Different MIME-compliant mail readers
     exhibit different behavior, especially when dealing with
     "multipart" MIME messages (i.e. documents which have been split
     up into multiple messages), so check your local documentation on
     how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

mailto:[email-masked]
ftp://ftp.ietf.org/internet-drafts/draft-renkel-middlebox-tunnels-00.txt

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Jul 2002 15:16:19 -0400

The idea that tunnels can solve the NAT problem without changes to 
applications is critically flawed - the technique only works if
the application somehow has a tunnel to a location in the network
that is simultaneously accessible by all of that application's peers,
and if the application knows to use the interface/address associated
with that tunnel in preference to all other interface/address pairs
available to it.

It's certainly better than nothing, and probably better than other
things that Midcom has produced.  but it's not a general solution.

Keith

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 01 Jul 2002 14:43:29 -0500

Tunneling also limitted to non-overlapping address space generally (at the
midcom side of the tunnel), and is not easily scaled....for multiple
overlapping address space even if individual MIDCOM solutions are
implemented to address this shortcoming...unless NAT or proxying is
implemented at the MIDCOM end to address this which means that we move the
problem closer to the agregate end.

I am rambling again... lets see what comes of it..I think it is a viable
alternative that has these limitations.

:^)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Keith Moore
Sent: Monday, July 01, 2002 2:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [midcom] FWD: I-D
ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

Keith