On Mon, 29 Nov 1999 22:45:17 PST, Ian King said:
> any "lack" because of it. I don't play UDP-based games or employ any of the
> other relatively new protocols that are so sensitive to end-to-end-ness
> (should they be? was that a valid assumption?), so a NAT is a great solution
Well.. Urm... TC
Hi Tony,
Well, the statement below is not true -- I sit behind a NAT/PAT
device and Real PLayer works just fine for me. I've only found a
couple of applications that will not work for me (e.g. ICQ, NTP,
SNMP), but then again, I'm not a gamer so I can't speak to the
broader range of applications t
> And yes, additional IP addresses were going to cost dramatically more. NAT
> was a simple case of economics... but on the other hand, I don't experience
> any "lack" because of it. I don't play UDP-based games or employ any of the
> other relatively new protocols that are so sensitive to end-t
Paul Ferguson wrote:
>
> Hi Tony,
>
> Well, the statement below is not true -- I sit behind a NAT/PAT
> device and Real PLayer works just fine for me. I've only found a
> couple of applications that will not work for me (e.g. ICQ, NTP,
> SNMP), but then again, I'm not a gamer so I can't speak to
> The NAT problems only
> start when the protocol carries IP address/port information (such
> as the FTP 'PORT' command), and the NAT isn't aware of that protocol's
> translation requirements
this is a popular misconception; it's a bit like saying that y2k
only breaks programs that store years i
1) It doesn't have to stay that way with IPv6 or an equivalent technology.
2) That's good news. More details would be useful.
3) I think this is a red herring. With most organizations moving to DHCP and many to LDAP-driven policy management, this is completely possible. What makes you argue th
> In any event, I've always personally been of the opinion that
> if applications don't work in the face of NAT, then the
> applications themselves are functionally deficient and should be
> fixed. :-)
I'm certainly not going to disagree with you about that,
but H.323 does not work through NAT w
While it is important to focus on building protocols that are as functional as possible in as many different environments as possible, I find the statement that protocols are "functionally deficient" that do not take NAT and firewalls into account to be misguided. The ultimate goal of a network,
--- Keith Moore <[EMAIL PROTECTED]> wrote:
> > And yes, additional IP addresses were going to cost dramatically more. NAT
> > was a simple case of economics... but on the other hand, I don't experience
> > any "lack" because of it. I don't play UDP-based games or employ any of
> the
> > other
Valdis Kletnieks wrote:
> However, I do agree that anybody designing a protocol in the last 3-4
> years *should* have designed it to be firewall and NAT friendly.
> (Yes, I know that can be difficult in practice. I guess that's today's
> "Welcome to Reality").
Daniel Senie wrote:
> > In any ev
[EMAIL PROTECTED] wrote:
>
> > In any event, I've always personally been of the opinion that
> > if applications don't work in the face of NAT, then the
> > applications themselves are functionally deficient and should be
> > fixed. :-)
>
> I'm certainly not going to disagree with you about tha
> Keith - There is no denying that NAT devices break a bunch of applications
> and protocols. But, they did get us through the rough times when IP
> addresses are scarce and many people wanted to hop on the Internet. In a
> way, NATs helped people keep their trust in IP and in the engineering
>
--- Keith Moore <[EMAIL PROTECTED]> wrote:
> > Keith - There is no denying that NAT devices break a bunch of applications
> > and protocols. But, they did get us through the rough times when IP
> > addresses are scarce and many people wanted to hop on the Internet. In a
> > way, NATs helped peo
At 3:04 -0500 11/30/99, [EMAIL PROTECTED] wrote:
>On Mon, 29 Nov 1999 22:45:17 PST, Ian King said:
>> any "lack" because of it. I don't play UDP-based games or employ any of the
>> other relatively new protocols that are so sensitive to end-to-end-ness
>> (should they be? was that a valid assumpt
--- Henning Schulzrinne <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > > In any event, I've always personally been of the opinion that
> > > if applications don't work in the face of NAT, then the
> > > applications themselves are functionally deficient and should be
> > > fixed.
*>
*> I'll grant FTP an exemption, it came well before NAT units became
*> prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).
There certainly was. FTP and Telnet were both ARPANET NCP protocols
in use since ~1972.
Bob Braden
*> However, I do agree that anybody d
> If you could design applications that can work with NAT
> enroute, without needing an ALG; that would be great.
> But, if the applications do require an ALG enroute
> (as in the case of voice-over-IP which uses out-of-band
> call-control segnalling), then the application designers should als
I think the below statement provides important perspective. NAT is not the
Antechrist, nor is it salvation. Much of the work on "improving" NAT seems
much like "improving" the Band-Aid so it will last for a year, although no
one wears one for more than a couple of days! When IPv6 is deployed an
At 09:15 30/11/99 -0500, Daniel Senie wrote:
>> In any event, I've always personally been of the opinion that
>> if applications don't work in the face of NAT, then the
>> applications themselves are functionally deficient and should be
>> fixed. :-)
>
>Indeed. While some in the IETF have stompe
Bottom line, NAT or changing destination addresses on the fly breaks the
end-to-end nature of Internetworking. This is true not only for IP, for for
other protocols as well. Some may recall older DECNET IV networks that
exceeded the maximim ~65K nodes. We had to come up with a scheme to make
t
> At 09:15 30/11/99 -0500, Daniel Senie wrote:
>
> >> In any event, I've always personally been of the opinion that
> >> if applications don't work in the face of NAT, then the
> >> applications themselves are functionally deficient and should be
> >> fixed. :-)
> >
> >Indeed. While some in the
> It seems to me that we may be able to recapture some aspects of end-to-end
> transparency at the application level if addressing issues are focused on
> host FQDNs, rather than IP addresses.
Forget about it. Many of the same folks doing NAT also do a
two-faced DNS which hides most of their nam
--- Matt Crawford <[EMAIL PROTECTED]> wrote:
> > It seems to me that we may be able to recapture some aspects of end-to-end
> > transparency at the application level if addressing issues are focused on
> > host FQDNs, rather than IP addresses.
>
> Forget about it. Many of the same folks doing N
Title: RE: IP network address assignments/allocations information?
Valdis,
This is the kind of BS that keeps these debates running. NAT problems exist anytime a connection originates on the public side and there is not a preexisting clear mapping to the private side. I didn't pick on Real P
At 11:28 -0500 11/30/99, Tony Dal Santo wrote:
>Valdis Kletnieks wrote:
>
>> However, I do agree that anybody designing a protocol in the last 3-4
>> years *should* have designed it to be firewall and NAT friendly.
>> (Yes, I know that can be difficult in practice. I guess that's today's
>> "Welc
Tony,
I wouldn't be so quick to characterize NAT as a "dead-end" technology.
Personally, I think NAT is just fine, but I'm a self-proclaimed cynic
and also consider myself somewhat of a pragmatist. In any event, it
works for me, but I could certainly be in the minority.
I think most of the hoop
John Day <[EMAIL PROTECTED]> writes:
>
> Correct. Lets get an application name space so we don't need to worry
> about it.
>
Please gods below, not more ASN.1
--
Mark Atwood |
[EMAIL PROTECTED] |
http://www.pobox.com/~mra |
On Tue, 30 Nov 1999 13:37:33 PST, "Tony Hain (Exchange)" said:
> This is the kind of BS that keeps these debates running. NAT problems exist
> anytime a connection originates on the public side and there is not a
> preexisting clear mapping to the private side. I didn't pick on Real Player
I said
The IETF+Censored mailing list
At times, the IETF list is subject to debates that have little to do
with the purposes for which the IETF list was created. Some people
would appreciate a "quieter" forum for the relevant debat
unsubscribe
Unsubsribe
Julio Novomisky
Abre gratis una cuenta de email en StarMedia Mail. El mejor servicio de email gratis de toda Latinoamérica. http://www.starmedia.com
Hello:
Just in case interested, there are some NomCom related artifacts
(1992-2000) at:
http://gnIETF.vlsm.org/#NomCom
regards,
--
-- Rahmat M. Samik-Ibrahim ---
-- OSI: Same day service in a nanosecond world --- Interop T-shirt(vJ)
> It seems to me that we may be able to recapture some aspects of end-to-end
> transparency at the application level if addressing issues are focused on
> host FQDNs, rather than IP addresses.
this works to some extent. it specifically doesn't work for applications
that need to rendezvous with s
At 18:12 -0500 11/30/99, Mark Atwood wrote:
>John Day <[EMAIL PROTECTED]> writes:
>>
>> Correct. Lets get an application name space so we don't need to worry
>> about it.
>>
>
>Please gods below, not more ASN.1
What a strange reaction!? What does an arcane syntax notation have to do
with Shoch'
*>
*> The problem is not to make applications "NAT aware" or "NAT friendly". The
*> problem is to make applications "IP address unaware". What is an
*> application doing exchanging and using names for things 2 layers below it?
*> Sounds like a design for trouble if I ever heard of o
Crypto Advocate Under FBI Investigation
Windows NT Magazine
Tuesday, November 30, 1999 - We recently published a
story regarding cryptography and IPv6, where somseone at
the Department of Justice accused Scott Bradner,
http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=167&TB=news
Internet En
> DNS is not secure
True for now. Of course, this is something DNSSEC is supposed to address.
> Authentication information is frequently encrypted
Not in the case of DNSSEC.
Rgds,
-drc
unsubscribe
> >> However, I do agree that anybody designing a protocol in
> the last 3-4
> >> years *should* have designed it to be firewall and NAT friendly.
> >> (Yes, I know that can be difficult in practice. I guess
> that's today's
> >> "Welcome to Reality").
> >
> >> > In any event, I've always perso
On Tue, 30 Nov 1999, Dr. Jai Maharaj wrote:
> We learned that
> William Allen Simpson, a Detroit-based computer
> consultant who was on the IETF staff, has been
> investigated by the federal government for treason
> charges.
Having been one of those interviewed by the FBI WRT W.A. Simpson, and
40 matches
Mail list logo
