Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Many SBC vendors would agree with your assessment. They would then add a list of the other advantages for putting application layer functionality into the network. The problems of this approach are, however, well-known. Hence, I would like to avoid them by decoupling the two interactions.

Ciao
Hannes

Hallam-Baker, Phillip wrote:
The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc.

The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes.

So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent:	Monday, July 16, 2007 01:30 AM Pacific Standard Time
To:	Brian E Carpenter
Cc:	Melinda Shore; ietf@xxxxxxxx
Subject:	Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

Hi Brian,

regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler.

There is a recent document that aims to compare some of the NAT / firewall protocol proposals:
http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt

It is not yet finished but might give you an idea what the different assumptions of some of the proposals are.

Ciao
Hannes

Brian E Carpenter wrote:
On 2007-07-14 00:07, Melinda Shore wrote:
On 7/13/07 5:43 PM, "michael.dillon@xxxxxx" <michael.dillon@xxxxxx> wrote:
I believe that we need a more general protocol for hosts inside a site
perimeter to communicate with the perimeter gateways and request
services from them.
We've actually got several of them, starting with SOCKS (which
could have been extended), continuing through RSIP, on to midcom
and SIMCO.  Note that "midcom" was so named under the assumption
that whatever was done would be extensible to other sorts of
middleboxes than firewalls and NATs

We could spend an awful lot of time talking about why none
of them has caught on, but I think it's fair to say that that
failure has not been caused by a perceived lack of generality.
Maybe by a lack of simplicity?

draft-woodyatt-ald-01 is a recent proposal.

    Brian

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]