Re: IP network address assignments/allocations information?
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... TCP and UDP both assume that one endpoint is talking directly in real time to another endpoint. 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 (If you see *this* at offset 80 of *that* packet, smash it to read *foobar* instead). 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?). 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"). Valdis Kletnieks Operating Systems Analyst Virginia Tech
RE: IP network address assignments/allocations information?
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 that it _does_ break. 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. :-) Cheers, - paul At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT.
Re: IP network address assignments/allocations information?
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-to-end-ness (should they be? was that a valid assumption?), so a NAT is a great solution for me. understood. and you may never miss any of those distributed applications or applications that want your end to be the "server" for the very reason that NAT prevents them from having enough market share to be successful. i.e. just because you don't know what you're missing doesn't mean that NAT hasn't done you harm. NAT would be bad if an ISP were using it to artificially expand its address space; the use of NAT at the "small-time" end user's site seems quite practical and beneficial, especially in a world where ISPs are going to hold up non-naive users for ransom. Cheers -- Ian if you think of NAT as a short-term strategy and are fully aware of its limitations, it probably won't cause you much harm as an individual. then again, there are dozens of products out there claiming to offer something like "internet connection sharing" without bothering to mention the limitations of that approach...which seems like misleading advertising at best. Keith
Re: IP network address assignments/allocations information?
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 broader range of applications that it _does_ break. Real added features to their protocol which permit it to work around most anything. These include using TCP instead of UDP if UDP doesn't work (probably how you're getting your streams, if you look at the statistics). I have found NTP (ok, SNTP) actually works fine through the NAPT implementation I use. A very large percentage of the protocols used by actual end users really do work, provided the servers are out on the public network. 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 stomped their feet and railed about how bad NAT is architecturally (something I suspect most folks concede) they've somehow believed it would be possible to offer a better solution and get NAT eliminated before it's widely deployed. Reality: it's extremely widely deployed, and must be taken into consideration when designing protocols. Those, like Real, who find ways to make their protocols work with NAT clearly will do better than those who do not. I've have thought I'd get a lot of feedback on the draft I've been working on in this area, draft-ietf-nat-app-guide-02.txt, but that's not been the case. New protocols should, in my opinion, provide descriptions of how they work or don't work with NAT. If there is a reason why they aren't going to work (carriage of port or address information), a description of how to build an Application Layer Gateway (ALG) should be provided. We are at a crossroads where architectural purity has intersected operational reality. At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: IP network address assignments/allocations information?
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 in two digits. see http://www.cs.utk.edu/~moore/what-nats-break.html for my attempt to list the various ways that programs can lose in the presence of NATs. Keith
RE: IP network address assignments/allocations information?
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 that such a transition isn't possible? It's much easier than (say) migrating operating systems. ssh -- Steve Hultquist, CTO and VP of Technology Leopard Boulder, Colorado, http://www.leopard.com/ Tony Hain (Exchange) [EMAIL PROTECTED] 11/29/99 11:44 AM To:Fleischman, Eric W [EMAIL PROTECTED], Randy Bush [EMAIL PROTECTED], 'Brian E Carpenter' [EMAIL PROTECTED] cc:Bill Manning [EMAIL PROTECTED], Pete Loshin [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:RE: IP network address assignments/allocations information? 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT. 2) Yes Microsoft plans to support IPv6, and work has started. 3) We have moved from a world where Internal/External (and the associated management burden) was an option, to one where it is required. If corporations wanted to remove their firewalls (using IPSec instead) they couldn't. -Original Message- From: Fleischman, Eric W [mailto:[EMAIL PROTECTED]] Sent: Monday, November 29, 1999 8:47 AM To: Randy Bush; 'Brian E Carpenter' Cc: Bill Manning; Pete Loshin; [EMAIL PROTECTED] Subject: RE: IP network address assignments/allocations information? A few questions for the list: 1) If we effectively ran out of addresses when RFC 1597 was published, has running out of addresses hurt us in any way? 2) Originally we had anticipated using IPv6 to save us from IPv4 address depletion. What's the status of IPv6? How does IPv6 traffic compare in volume with IPv4 traffic? Do non-IPv6-supporting vendors (e.g., Microsoft) have plans to eventually support IPv6? 3) Given the current situation of corporations using private addresses internally and a smaller set of global IPv4 addresses on their periphery, and a global IPv4 internet, one should theoretically be able to say how many public IPv4 addresses have been assigned and therefore how many remain unassigned and by so doing estimate how long until consumption. Why is this not possible in practice? -- From: Brian E Carpenter[SMTP:[EMAIL PROTECTED]] Sent: Friday, November 26, 1999 1:35 PM To: Randy Bush Cc: Bill Manning; Pete Loshin; [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? Well, let's not focus on Bill's data. Frankly, I haven't seen any data on this topic from any source that really convinces me that it means much. All I know is that we have thousands of sites using private address space, which completely falsifies any real data and makes it impossible to attach any real meaning to concepts such as running out of addresses. My personal opinion is that we ran out of addresses in practical terms around about when RFC 1597 was published. Brian Randy Bush wrote: www.isi.edu/~bmanning/in-addr-audit.html It does not cover specific /16 /24 delegations, it just looks at all of the SOA entries. Still, it does give a representation of how much space is delegated. uh, as these data appear to be the statistics of an attempt to walk the dns in-addr.arpa tree what confidence is there that this fairly represents address space assignment/allocation? e.g. there are 153 /16 announcements in 133.0.0.0 and the table at http://www.isi.edu/~bmanning/in-addr-data.html shows one in-addr.arpa allocation entries. e.g. there are 166 announcements (of 175 /16 equivalents of space) in 147.0.0.0 and the table at http://www.isi.edu/~bmanning/in-addr-data.html shows 193 in-addr.arpa entries. so how can the data at www.isi.edu/~bmanning/in-addr-audit.html be interpreted to give a useful representation of how much space is assignmed/allocated? randy
RE: IP network address assignments/allocations information?
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, in my mind, is to create an invisible connection between process running in distributed systems regardless of their location or connectivity. While protocol development is an appropriate place to address issues introduced by lower-level elements of the overall system, development of the lower levels should be focused on making development at higher levels as straight-forward as is practical. As has been discussed more exhaustively and ably by others than I am able to, NAT breaks this model. By introducing a single point-of-failure into the overall system and by also introducing artificial limitations linked directly to the temporary scarcity of address space, it is an anomoly in the overall development of the network system. The overall design philosophy for the network system, at least in my way of thinking, is one of inclusion and direct communication. We should endeavor to develop with that mindset. ssh Paul Ferguson [EMAIL PROTECTED] 11/30/99 05:10 AM To:Tony Hain (Exchange) [EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:RE: IP network address assignments/allocations information? 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 that it _does_ break. 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. :-) Cheers, - paul At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: IP network address assignments/allocations information?
--- 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 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 for me. understood. and you may never miss any of those distributed applications or applications that want your end to be the "server" for the very reason that NAT prevents them from having enough market share to be successful. i.e. just because you don't know what you're missing doesn't mean that NAT hasn't done you harm. 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 community as a whole to come up with solutions that meet the need of the time. Having said this, I do believe, people who market NAT devices should warn customers of the limitations and not pretend like there arent any. There are some folks who believe NATs are behind the creation of private addresses. The fact of the matter of the matter is the other way around. People have been using private addresses to build their networks; People change their providers, but do not want to renumber their networks each time they change their providers. NATs were able to provide connetivity to external world without requiring them to renumber their addresses in the private network. If nothing else, I would say that NATs were able to bring to bear an awareness in the minds of protocol/application designers a need to seperate names and addresses. That in itself seems like an accomplishment. NAT would be bad if an ISP were using it to artificially expand its address space; the use of NAT at the "small-time" end user's site seems quite practical and beneficial, especially in a world where ISPs are going to hold up non-naive users for ransom. Cheers -- Ian if you think of NAT as a short-term strategy and are fully aware of its limitations, it probably won't cause you much harm as an individual. then again, there are dozens of products out there claiming to offer something like "internet connection sharing" without bothering to mention the limitations of that approach...which seems like misleading advertising at best. I agree. Keith regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
[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 that, but H.323 does not work through NAT without extremely sophisticated stateful inspection/rewrite capabilities in the NAT, and it will not work, period, if the signaling streams are encrypted. For better or worse (and let's not get into that), there's a lot of H.323 out there and there's going to be much, much more over the coming years. RSIP isn't going to work cleanly with H.323, either (although there are some rather disgusting things you can do in the application about that). Agreed. Any protocol that wants to have out-of-band control will have difficulties with existing NATs (without ALGs). Thus, by saying "let's design NAT-friendly protocols", we are effectively ruling out a whole class of designs and only allow protocols with outgoing TCP connections (and possibly UDP request-response protocols). In the case of telephony, it would mean keeping a TCP connection open continuously to some outside server that would then use that TCP connection to send incoming calls behind the NAT. Thus, this is not just a matter of existing software, but fundamentally restricting protocol design to a very narrow class of design choices, choices which are basically inappropriate for anything related to efficient multimedia carriage (real-time multimedia over TCP isn't exactly a great option). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Re: IP network address assignments/allocations information?
* * 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 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"). * *Valdis Kletnieks *Operating Systems Analyst *Virginia Tech * *
RE: IP network address assignments/allocations information?
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 Player at random. My house is connected through a NATPT, and my wife couldn't get a video stream opened back to her machine. If I had pre-mapped those ports to her machine, then my son would not have been able to get them on his. If I pre-map them, all the bogus security arguments about NAT become invalid. Clearly NAT has allowed me to create an environment which is not sustainable, but at least I know enough to know what the problem is, the average guy on the street doesn't stand a chance. Yes there are problems with protocols that carry addresses, but ignoring encrypted traffic that really amounts to acquiring and synchronizing deployments of ALGs. In the early stages this doesn't sound hard, but will vendors be willing to add new ALGs to 3 year old NAT hardware? Will they create an update process that is easy enough for the average user? Will the average user be able to figure out which NAT needs updating, and what version it needs? Add the fact that people want to encrypt their traffic for privacy, and one wonders why so much effort is spent on this dead-end technology. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 30, 1999 12:05 AM To: Ian King Cc: [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? 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... TCP and UDP both assume that one endpoint is talking directly in real time to another endpoint. 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 (If you see *this* at offset 80 of *that* packet, smash it to read *foobar* instead). 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?). 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). Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: IP network address assignments/allocations information?
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 |
Unsubsribe
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
NomCom Artifacts
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)
Re: To address or NAT to address?
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 specific processes on specific hosts (or which need to use specific interface addresses, say for performance reasons), since a single FQDN often corresponds to multiple hosts. (or, less frequently, to multiple addresses on a single host). note also that DNS is often slow, and seems less reliable than IP. by increasing the reliance on DNS you increase the probability of failure.
Re: IP network address assignments/allocations information?
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's observation that there are 3 kinds of addresses: applications, hosts, and routes? What have you been smoking? -- Mark Atwood | [EMAIL PROTECTED] | http://www.pobox.com/~mra |
Re: IP network address assignments/allocations information?
* * 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 one. I don't believe this argument, John. The IP address is (part of) the transport layer end point address, something that an application can reasonably be expected to know about in the existing Internet architecture. Bob Braden
Crypto Advocate Under FBI Investigation (For Treason)
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=167TB=news Internet Engineering Task Force (IETF) area coordinator, of an anti-social act by trying to get encryption inserted into the new protocol. Later, at an IETF meeting where votes were taken for IPv6 encryption inclusion, Fore System's Brian Rosen brazenly claimed that regardless of any encryption inclusion, Fore systems would proceed by including back doors http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=177TB=news into any included encryption technology. But the harrassment of the IETF doesn't stop there. Just how far will our federal government go towards controlling strong encryption? Apparently, very far. And this isn't a new effort by any means. 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. Simpson was the person that argued loudly for encryption to be included in the PPP protocol when it was still in design phases. That push landed Simpson in hot whatever with federal officials. Simpson learned through friends that he was under investigation for treason -- the FBI had been interviewing his friends and associates. Simpson obtained 54 pages of documents from the government under the Freedom of Information act, however the documents were heavily censored, including the bureau's basis for the investigation. According to a ZDTV report, http://www.zdnet.com/zdtv/cybercrime/chaostheory/story/0,3700,2398590,00.html Simpson did learn that the FBI had accused him of "challenging authority and laws that may impinge upon his activities." Wait a second! Isn't that part of what the Constitution is all about--the means to peacefully object to the laws of the land? I think so. And if that's true, then that certainly positions the FBI in a bad light since it would appear their actions are counter to the Consitutional rights. It not against the law to develop strong cryptography, but it is against the law to export that technology outside of proper governmental controls. The PPP protocol did not have encryption at the time--it was only a suggested inclusion--so why investigate a person for doing something completely legal? The IETF is an open public standards body that conducts its business in clear public view. They help stear standards that better ensure compatibility and interoperability. So why would the FBI investigate an IETF member just because that person suggested in a public meeting that strong encryption be included in a standard wide-spread protocol such as PPP? Source - http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=186TB=news Not for commercial use. Solely to be fairly used for the educational purposes of research and open discussion. Jai Maharaj [EMAIL PROTECTED] Om Shanti
