Re: IP network address assignments/allocations information?
At 16:25 14/12/99 -0800, Dave Crocker wrote: At 02:50 PM 12/14/1999 , Christian Huitema wrote: No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. Only minimally, as long as a TCP connection is tied to an IP address... d/ ps. Christian and I separately suggested changing this, to support IP mobility, a few years ago. Would IPv6 anycast not be an alternative approach here? #g Graham Klyne ([EMAIL PROTECTED])
Re: IP network address assignments/allocations information?
Sure, I'm quite aware that there are many such tricks in use. I may even have helped to commit one or two of them in my former life. But the architecture of name resolution for IPv6 is as I described - if there are multiple records, you get multiple answers and the host gets to choose. Brian "David R. Conrad" wrote: Brian, DNS doesn't make a choice. If there are multiple addresses, it returns all of them. The host makes the choice. Let me introduce you to today's current crop of DNS-based load balancing "solutions". For example, from http://www.resonate.com/products/global_dispatch/faqs.php3: How does Global Dispatch relate to DNS architectures? Global Dispatch is an authoritative DNS solution- meaning that it integrates into a DNS architecture- but actually replaces existing 'dumb' authoritative DNS capabilities. The Global Dispatch scheduler sits behind an existing authoritative DNS server, such as BIND or Microsoft's DNS server. Global Dispatch resolves a virtual hostname into the IP address of a physical POP. When a client's local DNS server makes an address resolution request for a virtual hostname, Global Dispatch responds with the IP address of the most available physical POP based on latency and load information it receives from agents installed at each POP. Rgds, -drc
Re: IP network address assignments/allocations information?
Christian, First all of, it's good that we agree that we have a problem or problems to solve. Whether I overstated the problem or you under-estimated the problem is yet to be seen. In your message, you did not address the issue of how a host intelligently choose one of its multiple ip addresses as its source address when initiate a connection. This is an issue. For example, a host X with two IP addresses A1 and A2. When it sends a packet to host Y, it chooses A1 as source address, that means Y will use A1 as destination address when sending traffic back to X. If at the time, A1 is not routable at Y's network, (due to outage,etc.), Y will not be able to send traffic back to X resulting no reachability between X and Y. At all this time, A2 could be perfectly routable from Y's network, should X choose A2 instead of A1 as its source address, Y would be able to send traffic back to X thus communicating with X. X picked wrong address as source address simply because if has no routing knowledge beyond its local network. In short, we can have an unnecessary outage just due to the fact that host picking 'wrong' address. This will potentially complicate trouble shooting or cause confusion. E.g. X can not reach Y due to the problem described above while at the same time, traffic initiated from Y can reach X with no problem because from DNS Y got A2 as destination to reach X. One can image other trouble shooting confusions resulting from multiple addresses per host, especially the majority of the host in the Internet with multiple addresses. Other part is that host X in the example has to get an IP address associated with Y to use as destination address to reach Y. It will query DNS and DNS will return an IP address. You seems to indicate that there are two ways of doing this : 1) DNS intelligently determines which path is less congested and picks the appropriate address and 2) DNS just randomly picks one address among multiple addresses associated with a host. For 1), how does DNS gain knowledge of congestions of networks along the path? The congestion picture changes frequently, how how often will the knowledge get updated? I do not believe any such mechanism is defined at this point and it'd be interesting to see a mechanism that works and is scalable. Random selection of address is easier but it introduces unpredicatable behavior: a host will take different path to send traffic to the same destination host depending on what address DNS picking. Unpredicatability is always not friendly to operation and trouble shooting. In comparison to BGP, it picks routes in a predicatable fashion based on well known rules of BGP and network administrator's policies. Also, in both random selection or picking based on congestion cases, DNS should pick an address which is routable at the time. How does a DNS server know if an address is routable several hops away? It needs to have routing knowledge. Then how DNS get Internet routing knowledge and how often will it be updated? Again, it'd be interesting to see a proposal which works and scalable. cheers! --Jessica --- Forwarded Message Return-Path: [EMAIL PROTECTED] Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id PAA07772 for [EMAIL PROTECTED]; Tue, 14 Dec 1999 15:32:13 -0500 (EST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id PAA20805 for [EMAIL PROTECTED]; Tue, 14 Dec 1999 15:32:08 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA22236; Tue, 14 Dec 1999 15:30:46 -0500 (EST) Received: from pluto.cc.telcordia.com ([128.96.14.7]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA12656; Tue, 14 Dec 1999 15:30:43 -0500 (EST) Received: from uunet-14-7.cc.telcordia.com ([128.96.14.7]) by pluto.cc.telcordia.com via smtpd (for mailee.research.telcordia.com [192.4.7.23]) with SMTP; 14 Dec 1999 20:30:36 UT Message-Id: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 14 Dec 1999 15:26:59 -0500 To: Jessica Yu [EMAIL PROTECTED] From: Christian Huitema [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 3725 At 02:07 PM 12/14/99 -0500, you wrote: Brain, Looks like we have a teminology issue. Notice I did not say routing system but ROUTING will have problem. Because the choice of a multi-addressed host to use one of its IP address to include in packet header implies routin
Re: IP network address assignments/allocations information?
address assignments/allocations information? Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 3725 At 02:07 PM 12/14/99 -0500, you wrote: Brain, Looks like we have a teminology issue. Notice I did not say routing system but ROUTING will have problem. Because the choice of a multi-addressed host to use one of its IP address to include in packet header implies routing decision, the host, in effect, does some routing decision making. How a host intelligently choose the ip address as the source address to send packets or DNS intelligently choosing an ip address for a query are complex issues which we do not have an answer for as you indicated in your message. Jessica, I believe you overstate the problem. To begin with, a domain manager is never obliged to advertize all possible routing prefixes for all its hosts. In principle, it will only advertize those network connections that are deemed "good enough." So, at a 10,000 feet level, picking an address at random in the list, without any information whatsoever, gives you a connection that may not be optimal, but is probably reasonable. Which means that the proverbial "five lines client", which presumably will transfer 5 packets, will get adequate service. You will tell me that this may not be optimal, but then, explain me exactly how the current BGP fabric guarantees that routes are picked optimally? In fact, in their communication at the last ACM SIGCOMM conference, "On Estimating End-to-End Network Path Properties", Mark Allman and Vern Paxson observe that it is quite frequent for interdomain routing to converge on a less than optimal route today. The question indeed arises when one of the addresses in the list goes through a provider that is experiencing heavy congestion. Let's first remark that, if clients were to pick addresses at random from a list, we would obtain automatically some level of traffic spreading, which would generally tend to ease congestion -- but we all agree that congestion will not be eliminated. If the congestion is already present at the beginning of the connection, the answer is simple. The first SYN packet gets lost, and the client simply picks another address in the list and tries again. Again, this may not be optimal, but it will provide an adequate solution for even the most brain dead of clients. The smart clients will no doubt find how to resolve the problem in a smarter way. So lets focus on the remaining part of the problem. What happens if a client picks an address at the beginning of a connection, only to find out that the transit networks are becoming congested. There are solutions, which require minimal adaptation to TCP. An example is discussed at http://www.chem.ucla.edu/~beichuan/etcp/; another solution is developed as part of MobileIP. Indeed, if there is no modification to TCP, there is no good solution. But then, this is not very different from the current state of the art. a TCP connection can only survive the loss of a transit network if BGP manages to detect and correct the loss faster than it takes for the TCP timers to break. If I believe the recent reports to Nanog, this is far from guaranteed today. So, yes, we have a problem. We need to somehow adapt the TCP stack to survive losses of transit networks. But we should not overstate that problem. It only affects long connections, it only makes a difference if a connection to a transit provider breaks, and if the routing tables could have been repaired by BGP. In any cases, there are simple modification to TCP, for which we already have some experience, that could handle the problem. In the long run, once these modifications are in place, we are better off than in the current situation, because we will rely less on the speed at which interdomain routing converges. - -- Christian Huitema --- End of Forwarded Message -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: [EMAIL PROTECTED] Ethernet address: 00-00-AC-CF-5B-82
Re: IP network address assignments/allocations information?
Brian, DNS doesn't make a choice. If there are multiple addresses, it returns all of them. The host makes the choice. Let me introduce you to today's current crop of DNS-based load balancing "solutions". For example, from http://www.resonate.com/products/global_dispatch/faqs.php3: How does Global Dispatch relate to DNS architectures? Global Dispatch is an authoritative DNS solution- meaning that it integrates into a DNS architecture- but actually replaces existing 'dumb' authoritative DNS capabilities. The Global Dispatch scheduler sits behind an existing authoritative DNS server, such as BIND or Microsoft's DNS server. Global Dispatch resolves a virtual hostname into the IP address of a physical POP. When a client's local DNS server makes an address resolution request for a virtual hostname, Global Dispatch responds with the IP address of the most available physical POP based on latency and load information it receives from agents installed at each POP. Rgds, -drc
Re: IP network address assignments/allocations information?
Christian Huitema wrote: The first SYN packet gets lost, and the client simply picks another address in the list and tries again. The APIs I've used don't tell me about lost SYN packets (thank goodness); they only tell me if the connection has timed out. So, yes, we have a problem. We need to somehow adapt the TCP stack to survive losses of transit networks. But we should not overstate that problem. It only affects long connections, (a) But long connections are important; they're more efficient (and give the users better performance) than short connections. Modern application protocols are being designed with this in mind. (b) It also affects short connections, just not as often. If Joe User's HTTP connection gets dropped, he'll see "Transfer interrupted" and think there's something wrong with the server (or he'll see a broken image and think the site's HTML is messed up). It would not occur to him that the trouble would be in a transit network; he's probably never heard the term. So he'll come away thinking that the Internet is just plain flaky. it only makes a difference if a connection to a transit provider breaks, Or if the chosen path becomes congested over time. In any cases, there are simple modification to TCP, for which we already have some experience, that could handle the problem. In the long run, once these modifications are in place, we are better off than in the current situation, OK. How long is the long run? How long did it take to get the LFN fixes deployed? They were described in 1989 (RFC-1106); I seem to remember they weren't widely available as of 1994 or so. (My memory may be skewed, though, because one of the machines I was using was running SunOS 4.x, which wasn't being updated much.) -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |They prayed for their fates to be quick, | |[EMAIL PROTECTED]|painless, and, ideally, someone else's. | \==/
Re: IP network address assignments/allocations information?
At 04:29 PM 12/14/99 -0500, John Stracke wrote: it only makes a difference if a connection to a transit provider breaks, Or if the chosen path becomes congested over time. No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. -- Christian Huitema
Re: IP network address assignments/allocations information?
At 02:50 PM 12/14/1999 , Christian Huitema wrote: No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. Only minimally, as long as a TCP connection is tied to an IP address... d/ ps. Christian and I separately suggested changing this, to support IP mobility, a few years ago. =-=-=-=-= Dave Crocker [EMAIL PROTECTED] Brandenburg Consulting www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA
Re: IP network address assignments/allocations information?
At 02:50 PM 12/14/1999 , Christian Huitema wrote: No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. Only minimally, as long as a TCP connection is tied to an IP address... d/ ps. Christian and I separately suggested changing this, to support IP mobility, a few years ago. indeed, and something like this appears to have surfaced again, albeit briefly, in the IPNG working group.. see the sep/oct section of http://playground.sun.com/pub/ipng/html/meetings.html particularly, the "Preserving Active TCP Sessions ( pdf ), P. Tattam " - Bill
Re: IP network address assignments/allocations information?
it's not at all clear that this can work well enough to be a general purpose multihoming mechanism, at least not without adding a fair amount of extra infrastructure and complexity - i.e. a mechanism which hosts or applications can use to query the network to determine relative proximity of several different addresses. There is also a potential scaling issue of using multiple addresses as general purpose multihomging mechanism. This is because if this is the case, most of the Internet hosts will end up with multiple addresses. Based on the current assignment strategy, only top-tier ISPs (networks) will be assigned with TLAs. tier-2 ISPs will get allocation address space from the TLAs of their connected tier-1 ISPs. If a tier-2 ISP is multihomed, the ISP will be assigned with two IP addresses from two different TLAs. All the downstream customers of this tier-2 ISP will get multiple addresses for each host. Since most of the tier-2 ISP (if not all) will be multihomed to tier-1 ISPs for redundancy purpose, most of the Internet hosts will end up with multiple IP addresses. Only tier-1 ISPs' direct connected single-homed customers will not have multiple addresses for their hosts. It's possible that some multihomed sites will have to assign 4 or even more ip addresses per host, depend on what kind of ISPs they multihoming with. E.g. a site that happen to multihome to two tier-2 ISPs, each multihomed with two different tier-1 ISPs, each host in this multihomed site will have 4 IP addresses in order to get full benefit of redundancy. One can image even more complicated case. So I think we need to explore different ways of doing multihoming. --Jessica Date:Thu, 09 Dec 1999 19:36:28 EST To: Christian Huitema [EMAIL PROTECTED] cc: Sean Doran [EMAIL PROTECTED], [EMAIL PROTECTED] From:Keith Moore [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? Return-Path: [EMAIL PROTECTED] X-URI: http://www.cs.utk.edu/~moore/ In-reply-to: Your message of "Thu, 09 Dec 1999 18:14:18 EST." [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Content-Type: text Content-Length: 1465 Let's put it this way: the registries are instructed that only top level providers should get one of these addresses. Everyone who does not qualify supposedly get a delegation from a TLA, or several delegations in the case of multi-homed networks. of course, this requires that sending hosts or applications make intelligent decisions about which destination address to use (and which source address to use with a particular destination address), usually in the absence of any information which might inform the decision. it's not at all clear that this can work well enough to be a general purpose multihoming mechanism, at least not without adding a fair amount of extra infrastructure and complexity - i.e. a mechanism which hosts or applications can use to query the network to determine relative proximity of several different addresses. if it does turn out to work it will probably be because all of the available prefixes for both the source and destination host are so reliable and have so much available bandwidth that most of the time that it doesn't matter which of the available addresses you use. (it's tempting to say that multihoming will work quite well for those cases where you don't need multihoming... but that is a bit of an exaggeration) to be fair, "traditional" multihoming doesn't scale well enough to use that approach either. maybe we just need for Internet service to be as reliable as telephone service. Keith
Re: IP network address assignments/allocations information?
Keith Moore wrote: and just because I have multiple devices in my home doesn't mean that I trust my (roommate, spouse, kid, babysitter, houseguest, burglar, landlord, friendly neighborhood cop) to have net access to everything in my home merely by having physical presence there. Download an ActiveX control and your garage door opens and your security system shuts down... -- /=\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist || |eCal Corp. |You're just jealous because the voices only talk| |[EMAIL PROTECTED]|to me. | \=/
Re: IP network address assignments/allocations information?
There is also a potential scaling issue of using multiple addresses as general purpose multihomging mechanism. This is because if this is the case, most of the Internet hosts will end up with multiple addresses. I don't see why this is inherently a problem. It's possible that some multihomed sites will have to assign 4 or even more ip addresses per host, depend on what kind of ISPs they multihoming with. E.g. a site that happen to multihome to two tier-2 ISPs, each multihomed with two different tier-1 ISPs, each host in this multihomed site will have 4 IP addresses in order to get full benefit of redundancy. One can image even more complicated case. I believe that it should be fairly straightforward to extend implementations to deal with this case; some of the proposals floating about actually significantly simplify the API's used by real applications. - Bill
Re: IP network address assignments/allocations information?
There is also a potential scaling issue of using multiple addresses as general purpose multihomging mechanism. This is because if this is the case, most of the Internet hosts will end up with multiple addresses. I don't see why this is inherently a problem. it's a problem because it's essentially asking the sending host to do routing in the absence of any routing information. if multiple addresses are available for a host, the chances are good that the paths associated with some of those addresses are significantly better, or worse, than others. with IPv4 multihoming, the routing system sorts out which path to use. this doesn't work perfectly but at least the decision is made in light of some information about the nature and current state of those paths. with IPv6 multihoming, the sending host is just guessing. it's difficult to believe that this will work well.
Re: IP network address assignments/allocations information?
Actually, I think this is the case more often than many people may realize. Right now, for example, one of my sites is running in this mode for exactly this reason. Yes, there are issues, but not ones that aren't relatively easily mitigated. ssh -- Steve Hultquist, CTO and VP of Technology Leopard Boulder, Colorado, http://www.leopard.com/ Jessica Yu [EMAIL PROTECTED]To: Bill Sommerfeld [EMAIL PROTECTED] cc: Jessica Yu [EMAIL PROTECTED], Keith Moore [EMAIL PROTECTED], 12/10/1999 Christian Huitema [EMAIL PROTECTED], Sean Doran 01:01 PM [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? There is also a potential scaling issue of using multiple addresses as general purpose multihomging mechanism. This is because if this is the case, most of the Internet hosts will end up with multiple addresses. I don't see why this is inherently a problem. This is paradigm shift in the Internet from majority of hosts with single IP address to the majority of the hosts with multiple IP addresses. Many existing support mechanisms such as routing (see Keith's message), DNS name look up, traffic engineering network managment,etc. may not be adequate. It may also break the things that we have not even thought of. And do not forget about operational complexity issues. Are we really ready for such a major shift? So I would not say so quickly that it's not a problem. --Jessica
Re: IP network address assignments/allocations information?
Keith Moore wrote: There is also a potential scaling issue of using multiple addresses as general purpose multihomging mechanism. This is because if this is the case, most of the Internet hosts will end up with multiple addresses. I don't see why this is inherently a problem. it's a problem because it's essentially asking the sending host to do routing in the absence of any routing information. First thing that came to my mind was "great, looks like token-ring source-routing." I'd hoped we learned our lesson on that one. Having end nodes attempt to make network path decisions is a monumentally BAD idea. if multiple addresses are available for a host, the chances are good that the paths associated with some of those addresses are significantly better, or worse, than others. with IPv4 multihoming, the routing system sorts out which path to use. this doesn't work perfectly but at least the decision is made in light of some information about the nature and current state of those paths. with IPv6 multihoming, the sending host is just guessing. it's difficult to believe that this will work well. I can imagine that a company which is multihomed to two or more ISPs, each of whom is tier-2 or below, may well have a dozen addresses to deal with, per host. Now somebody remind me of why we wanted all this extra address space? It was so we could give every machine a dozen addresses? Exactly how the end nodes are to know which of these addresses to use, especially when the decision point in the topology is several layers above (at the tier2 to tier1 provider attachment point) is going to be interesting. Token-ring source routing allowed relatively dumb bridges to be used. This protected the "core" of the network from having to have extra processing horsepower. Of course we soon saw Ethernet bridges and switches which could handle all of the needed decisions without the involvement of the end stations. We started down the path of MPLS to protect the core routers which were going to melt under the traffic load. Then vendors showed us hardware which could route packets at wire speed. Now we're busy pushing technology to ensure routing table sizes won't increase because the present generation of hardware can't handle larger routing tables. Are we being a bit short-sighted? -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: IP network address assignments/allocations information?
Sean Doran wrote: ... Are you of the belief that as a matter of policy, everyone but "top level" providers will have addresses from a "top level" provider, with no exceptions? Do you also beleive that for inter-TLA routing information-exchange purposes, with respect to the destination address, ONLY the 13 (to 21) TLA (+ RES) bits you mention should ever be considered by a router in the core of the global network, except where two directly-peering TLAs agree to exchange some NLA information? This is the plan. We start out with no holes in BGP and we try to keep it that way. Brian
Re: IP network address assignments/allocations information?
| so i had a nearby scheme interpreter yay. (now go fix all the buggy scheme and lisp packages in -current :) :) :) ) | It seems obvious to me that the only way routing can scale with | addresses this large is with very aggressive aggregation. It would work better still with abstraction, hence my (maybe stupid) questions to Brian and Christian. | The only way multihoming can work when aggressive aggregation is in | place is if hosts end up with multiple addresses (one from each | prefix) and know how to use them intelligently... Even trickier: how to get non-local hosts to use them intelligently. The DNS as a mechanism for policy-based routing (in the sense of remotely influencing other people's path selection) is not totally without appeal. But then again, I'm a loon, and like NAT. Sean.
Re: IP network address assignments/allocations information?
Ok, so it seems like there is a 1-1 mapping of TLAs to AS numbers -- in reality, with the current ipv6 allocation policy of the registries, all asns are using the same single tla. it's one of those theory and practice things. randy
Re: IP network address assignments/allocations information?
At 11:51 PM 12/9/99 +0100, Sean Doran wrote: Even trickier: how to get non-local hosts to use them intelligently. This is definitely a research issue. I think however that there are at least three possible solutions, and so I believe that this is not a very difficult research issue. The first solution is indeed what we do everyday: get several addresses from the DNS, pick one more or less at random, try it, and if it fails try the next one. The second solution is when your DNS resolver has acquired some knowledge of the Internet, and can sort the address list based on expected performance. Strict provider addressing actually makes this kind of knowledge acquisition slightly easier, as the knowledge table is essentially similar to a routing table, and thus subject to the same kind of aggregation. There are indeed many ways to acquire this knowledge, from looking at the routing tables to getting feedback from the hosts, and this is where research becomes interesting. The third solution requires TCP implementation that have the "zero context" hacks necessary to protect against SYN flooding attacks. In that case, the caller simply sends parallel SYN messages to all possible addresses, continue with the first response, and forgets anything else. Basically, you trade routing complexity for increased traffic. A related problem is the support of readdressing, i.e. changing the IP addresses without losing the TCP connection, but there are already solutions in the v6 spec. -- Christian Huitema
Gateways (Re: IP network address assignments/allocations information?)
At 09:34 08.12.99 -0800, Ed Gerck wrote: So, perhaps the same company could also make a NAT that any homeowner could use? Because if the problem of NATs is easy of use, and this is the key being banged here (the NY School Board example, etc.) then it is a problem of design. However, if the problem is concept, in which way are NATs different from gateways, conceptually speaking? And, gateways are useful, no? I like Einar Stefferud's gateway one-liner: "All gateways lose information. Some do it more efficiently than others." Someone once called this one "Alvestrand's equality": "Gateways = Pain". This was after too many years spent on email gateways. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
At 21:17 07.12.99 -0500, Daniel Senie wrote: Sounds to me like at best I'd trade a NAT box with firewalling for a serious firewall. Right. Insecure devices require protection, always. I have ZERO interest in allowing the kinds of things you describe to occur from outside. While you may not mind someone hacking into the microphone on your PC and using it as a bug I am a little less trusting. OTOH, if you combine NAT with 6to4 for home networks, the picture starts to look a bit better. Think of 6to4 as the generic ALG that rids you of the need to have separate ALGs for most of the applications that NAT happens to break. So, will any of our ISP readers go on the record as saying they'll provide users of dialup and DSL/Cable lines to have a large block of addresses each, instead of just a single host address? If you do the "native" IPv6 address assignment, it's impossible to route on anything smaller than a /64. You then have 2^63 addresses for manual configuration within the subnet, in addition to the ability to connect anything with a MAC address without an address clash. So the answer is "yes". -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
At 06:05 PM 12/7/99 -0800, Rick H Wesson wrote: randy, just because routers meltdown from leaks and mis-configurations is not a reasonable justification for ARIN's tight policies on IPv4 allocations, which kim stated earlier was to keep space aggrigated for router memory requirements, adding speed and processing power to that definition still does not justify the strict policy decisions. -rick Hmm, so you don't believe we should bother with aggregation of address space? You should come to an ARIN public policy meeting and propose this..should be interesting :-) Kim On Tue, 7 Dec 1999, Randy Bush wrote: it's not the memory. it's the processing power required which is quite non-linear. it's not the memory for the /24s in old b space, it's the horrifying *large* and *long* meltdowns caused by inadvertant leakage of bogus announcements of /24s in old b space randy
Re: IP network address assignments/allocations information?
Noel, From: Ed Gerck [EMAIL PROTECTED] maybe this is what the market wants -- a multiple-protocol Internet, where tools for IPv4/IPv6 interoperation will be needed ... and valued. This relates to an approach that seems more fruitful, to me - let's try and figure out things that sidestep this incredibly divisive, upsetting and fundamentally unproductive argument, and try and find useful things we can do to make things work better. Which can, undoubtably, be put in a sound theoretical framework for NATs, in network topology. NATs do not have to be a hack. Well, the fundamental architectural premise of NAT's *as we know them today* - that there are no globally unique names at the internetwork level - is one which is inherently problematic (long architectural rant explaining why omitted). So I don't think that the classic NAT model is a good idea, long-term. I would say that the fundamental architectural premise of NATs is that globally unique names at the internetwork layer are not carried in the network layer header. This is not to say that such names don't exist - just that they aren't in the IP header. Yakov.
Re: IP network address assignments/allocations information?
From: Yakov Rekhter [EMAIL PROTECTED] the fundamental architectural premise of NAT's *as we know them today* - that there are no globally unique names at the internetwork level I would say that the fundamental architectural premise of NATs is that globally unique names at the internetwork layer are not carried in the network layer header. This is not to say that such names don't exist - just that they aren't in the IP header. That may be true in some future variant of NAT - and if so, I'd be *much* happier with it (I don't any problem with limited use of names with local scope) - but my take is that it's not the case today. And no, DNS names are *not* what I was thinking of when I said "names at the internetwork level"! :-) For one thing, they don't contain *location* information. Noel
Re: IP network address assignments/allocations information?
"J. Noel Chiappa" wrote: From: Ed Gerck [EMAIL PROTECTED] maybe this is what the market wants -- a multiple-protocol Internet, where tools for IPv4/IPv6 interoperation will be needed ... and valued. This relates to an approach that seems more fruitful, to me - let's try and figure out things that sidestep this incredibly divisive, upsetting and fundamentally unproductive argument, and try and find useful things we can do to make things work better. I suggest we first revisit the concept of collaboration itself. IMO, collaboration can no longer be understood as similar agents doing similar things at the same time but as different agents doing different things at different times, for the same objective. Then, we can build protocols that will support this notion of collaboration, where diversity is not ironed-out by hypotheses but actually *valued* and used in interoperation. Which can, undoubtably, be put in a sound theoretical framework for NATs, in network topology. NATs do not have to be a hack. Well, the fundamental architectural premise of NAT's *as we know them today* - that there are no globally unique names at the internetwork level - is one which is inherently problematic (long architectural rant explaining why omitted). That fundamental premise is trivially true (so, no need for rant ;-) ). However, this is not what I was mentioning, as I think we are talking about something even more fundamental. A topology is simply a division of space, simply speaking. In these terms, data is no longer an absolute quantity. Indeed, when thinking about data in communication processes (networks) it has so far seemed possible and undisputed to regard data as information in numerical form that can be digitally transmitted or processed, and whose total quantity is preserved when a system is divided into sub-systems or when different data from different sources are compared. Actually, this picture is wrong to a large extent and NATs are the living proof of it -- there are natural laws also in cyberspace. The very concept of data needs thus to revisited. Suppose we define data as the *difference* D2 - D1 that can be measured between two states of data systems. Then, it can be shown that this difference can be measured by means of a communication process only if 1 and 2 are two states of the same closed system. When they are not, NATs are a solution to create a third-system, a common reference between 1 and 2. Which can be conceptual or physical or both, but is needed. In this formalism, a numerical value for data can be defined even though 1 and 2 may belong to different systems, or even though the data systems may be open -- the only restriction is to have a common reference. This is the mind-picture we need to overcome IMO -- that data is absolute. It is not and this answer implies that we need to find "data laws" in order to describe exchanges of data much in the same way as we needed to develop Thermodynamic laws in order to describe exchanges of energy (itself, not an absolute concept, either). So I don't think that the classic NAT model is a good idea, long-term. I suggest we don't yet have a "NAT model", in engineering sense, where a model fits in a larger model and so on. All we have is a "NAT hack". And, I agree that the NAT hack is not a good idea, even mid-term. However, I think it's a bit of a logical fault to think that the only options are i) IPv6 and ii) NAT's. Yes, especially NATs as they are -- somewhat born out of need, not so much design. NATs ... seem to have been discovered before being modeled, that is all. Umm, not quite, IIRC. Papers by Paul Tsuchiya and Van Jacobsen discussed the concept a long time before any were commercially available. Discussed the concept, as one may argue that telegraph systems also did when they needed to define telegraph codes in each station, so that different "John Smith" could respectively get their proper messages even though they all "shared" the same name. What I meant is not this. What I meant is an ab initio model of data in network systems, where NATs are one instance of a third-system that is *needed* in order to provide a common but quite arbitrary reference for "measuring" data between different systems, without requiring any change to them. In such a formalism, there are data levels NATs can handle and others it cannot, try as one may -- which needs to be recognized and provided for each case, by yet other objects. Cheers, Ed Gerck
Re: IP network address assignments/allocations information?
Harald Tveit Alvestrand [EMAIL PROTECTED] writes: A /48 leaves 16 bits for subnetting, before you hit the 64 bits of flatspace. And remember, if we ever need to, we can start subnetting the bottom 64 bits, at the loss of one form of stateless autoconf (which I'm starting to find, in deployment, is too unpleasant to use on my nets anyway).
Re: IP network address assignments/allocations information?
Lloyd Wood wrote: On Wed, 8 Dec 1999, Ed Gerck wrote: The very concept of data needs thus to revisited. Suppose we define data as the *difference* D2 - D1 that can be measured between two states of data systems. Then, it can be shown that this difference can be measured by means of a communication process only if 1 and 2 are two states of the same closed system. Since not all system state is communicated and any communication is a near-minimum abstraction of system state, this idea is a non-starter. I understand your doubts; this is a new approach. But communication is not a "near-minimum abstraction of system state" -- whatever you mean to communicate by that ;-) The very failure of your communication in that phrase (and, my very failure to communicate to you in my phrase) exemplifies my phrase, however. When they are not, NATs are a solution to create a third-system, a common reference between 1 and 2. Which can be conceptual or physical or both, but is needed. In this formalism, a numerical value for data can be defined even though 1 and 2 may belong to different systems, or even though the data systems may be open -- the only restriction is to have a common reference. This is the mind-picture we need to overcome IMO -- that data is absolute. It is not and this answer implies that we need to find "data laws" in order to describe exchanges of data much in the same way as we needed to develop Thermodynamic laws in order to describe exchanges of energy (itself, not an absolute concept, either). Absolute zero always seemed pretty damn absolute to me. There is no absolute value of energy associated with absolute zero temperature -- if that is what you mean. There are many quantities which are not absolute, distance is another example (besides energy and data). Phase is another. But there are absolute quantitites, of course. Taking your energy analogy further and better, NATs (and firewalls) are the protocol equivalent of Maxwell's demons; No. This analogy is not correct. Note also that Maxwell's demon has been proved not to be possible, even theoretically. What I meant is not this. What I meant is an ab initio model of data in network systems, where NATs are one instance of a third-system that is *needed* in order to provide a common but quite arbitrary reference for "measuring" data between different systems, without requiring any change to them. In such a formalism, there are data levels NATs can handle and others it cannot, try as one may -- which needs to be recognized and provided for each case, by yet other objects. For every type of molecule or energy level you might encounter, you have to add another demon. There are no demons here. If you agree that data is not absolute then my explanation follows. If you do not agree, then please tell me if "2=2" is true or false -- it is a simple expression, a simple data point given by "2=2". But your answer, whatever it is, will prove it is not absolute. What is the significance of this? Not to make matters more complicated but to recognize that NATs are not demons ;-) In other words, either we have *one* closed data system (IPv4, IPv6, etc.) where we can easily define data values by difference in data states (where an arbitrary value of zero is assigned to a system-wide reference state), or we have *many* systems where we need NATs to provide reference states between different systems in order to communicate between them. Since IPv6 defines a larger system, it can encompass a series of different IPv4 systems linked by NATs. However, since we *do* expect to encounter IPv4 systems, even if IPv6 is extremely sucessful (say, takes over 80% of the universe), then it follows that we will always need NATs to provide a common reference between different systems. Thus, it is worthwhile IMO to model them and use them well, not demonize them :-))) Cheers, Ed Gerck
Re: IP network address assignments/allocations information?
"Perry E. Metzger" wrote: Jon Crowcroft [EMAIL PROTECTED] writes: Having said that, I ask you: What do you foresee as a realistic IPv6 transition plan? Dual stacks? I don't see it happening, to tell you the truth. (Maybe this 6-in-4 stuff will actually help here.) well, how about we just start to turn it on in some routers? - it works in most host OSs now, dual stack, just fine. the value of the net is the square of the number of people connected - NAT is a square root function. NAT has actually created a simple transition plan for us. I'd say at this point that 95% of the corporate networks in the U.S. use private addressing and a NAT or proxy box at the border. Switching from this to using v6 internally with a v6 to v4 NAT/proxy at the border for communicating with v4 is trivial -- since they don't have globally routable addresses now, they won't be hurt by the switch. As more and more people switch to this configuration, they'll start finding themselves talking to more and more things over the net natively, and fewer and fewer through the translator. Suddenly, they'll discover they *do* have globally routable addresses again, just like we did in the old days before net 10 was turned into the universal addressing ghetto. By the way, the 6to4 mechanism was conceived as the natural first mechanism for such NATted sites to use. In answer to Yakov, the idea is that IPv6 site renumbering will be so much easier than for IPv4 that renumbering will be *less* painful than NATting. Theoretically this is taken care of in IPv6 today, but we need to see some practical experience of renumbering to find out if it's true. Brian
Re: IP network address assignments/allocations information?
Brian E Carpenter [EMAIL PROTECTED] writes: As more and more people switch to this configuration, they'll start finding themselves talking to more and more things over the net natively, and fewer and fewer through the translator. Suddenly, they'll discover they *do* have globally routable addresses again, just like we did in the old days before net 10 was turned into the universal addressing ghetto. By the way, the 6to4 mechanism was conceived as the natural first mechanism for such NATted sites to use. In answer to Yakov, the idea is that IPv6 site renumbering will be so much easier than for IPv4 that renumbering will be *less* painful than NATting. Theoretically this is taken care of in IPv6 today, but we need to see some practical experience of renumbering to find out if it's true. I'm not sure we're there yet in the support technology for renumbering. We have good ideas but we haven't pushed them totally out the door yet. However, we do have good ideas. -- Perry Metzger [EMAIL PROTECTED] -- "Ask not what your country can force other people to do for you..."
Re: IP network address assignments/allocations information?
the idea is that IPv6 site renumbering will be so much easier than for IPv4 that renumbering will be *less* painful than NATting. this needs to be reconciled with the *much* more conservative statements on v6 renumber-ability coming from respected v6 folk such as deering et alia. randy
Re: IP network address assignments/allocations information?
I'm not sure we're there yet in the support technology for renumbering. We have good ideas but we haven't pushed them totally out the door yet. However, we do have good ideas. [ flame, not directed at you personally but at this thread ] this is not the internet marketing task force. get real. a LOT of folk have deployed nat, hundreds every day. it's easy. it solves the customer's perception of their problem. it's not expensive. [ yes it sucks architecturally. what's that got to do with customer/market reality? the office buildings we work in suck architecturally too. ] we'll have to be at least three times (cheaper*better*easier) to replace nat, that's market reality. currently we are not proposing anything that the customer perceives as cheaper, better, or easier. this does not bode well. until we change this by making our technology, or at least the perceprion of it, cheaper, better, and easier, pontification, scare tactics, and nat- bashing make us look foolish and poison our credibility in the long term. randy
Re: IP network address assignments/allocations information?
Randy Bush [EMAIL PROTECTED] writes: get real. a LOT of folk have deployed nat, hundreds every day. it's easy. it solves the customer's perception of their problem. it's not expensive. It is *astonishingly* expensive. It only seems cheap until you have to maintain it. And yes, I'm going by Actual Live Customer Experience In Actual Live Large Companies. I'll keep posting this so long as people keep on with the "NAT is cheap and works well" myth. NAT is a fine solution for someone running three Macs and a Linux box behind a cable modem. It does not, however, scale, and This Costs Big Time. If you expect to run a large enterprise on NAT, be prepared to do the moral equivalent of ripping up $100 bills and flushing them down the toilet, hour after hour. -- Perry Metzger [EMAIL PROTECTED] -- "Ask not what your country can force other people to do for you..."
Re: IP network address assignments/allocations information?
"Perry E. Metzger" wrote: Randy Bush [EMAIL PROTECTED] writes: get real. a LOT of folk have deployed nat, hundreds every day. it's easy. it solves the customer's perception of their problem. it's not expensive. It is *astonishingly* expensive. It only seems cheap until you have to maintain it. And yes, I'm going by Actual Live Customer Experience In Actual Live Large Companies. The counter argument is that for the Home Networking case, which is a HUGE market, it is indeed cheap and easy to use. Please accept THAT reality. NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. I'll keep posting this so long as people keep on with the "NAT is cheap and works well" myth. NAT is a fine solution for someone running three Macs and a Linux box behind a cable modem. It does not, however, scale, and This Costs Big Time. If you expect to run a large enterprise on NAT, be prepared to do the moral equivalent of ripping up $100 bills and flushing them down the toilet, hour after hour. Fine. Let's focus on your corporate use of NAT issue, since that's where you have problems. I, for one, would like to hear more about how these companies are using NAT, and perhaps we can from there work toward some solutions. I'd suggested the other day allocation of a block of addresses, to be handed out by a registry in small chunks, specifically for use in interconnects between companies. I had heard lots of rumblings in the past that this is where NAT in large companies was causing trouble. From the lack of any response, perhaps the problem is otherwise. Since you're having such troubles, and since many of us apparently don't understand the situations where you're getting into trouble, please enlighten us. I've generally been of the opinion that NAT is a very workable solution for the small office and home network, and questionable for larger networks. Sounds like you're saying the same. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: IP network address assignments/allocations information?
It is *astonishingly* expensive. It only seems cheap until you have to maintain it. And yes, I'm going by Actual Live Customer Experience In Actual Live Large Companies. if it were easy to show this we would not be discussing the topic I don't know many companies who decide to do "*astonishingly* expensive" things if there are cheaper options Scott
Re: IP network address assignments/allocations information?
Daniel Senie [EMAIL PROTECTED] writes: It is *astonishingly* expensive. It only seems cheap until you have to maintain it. And yes, I'm going by Actual Live Customer Experience In Actual Live Large Companies. The counter argument is that for the Home Networking case, which is a HUGE market, it is indeed cheap and easy to use. Please accept THAT reality. I'm not even sure its a good thing there. You're at work. You want to check your answering machine. Its behind a NAT, so you can't. You want to program your VCR. You can't. Its behind a NAT... NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. I don't agree that NAT scales, ever. Its a great kludge if you are using it for a very limited number of things. As I said, letting two people surf the web behind one cable modem with one IP address works on a NAT. Does NAT scale to true home networks, where every light bulb is SNMP manageable? No. Does it scale even to a modest home network? Only if you think the sole application is letting you surf the web on your toaster, which I doubt is the future. Perry
Re: IP network address assignments/allocations information?
I've generally been of the opinion that NAT is a very workable solution for the small office and home network, and questionable for larger networks. Sounds like you're saying the same. The New York City Board of Education is using NATs as a security measure to keep their 1000+ schools off of the public network. Teachers are reporting that the networks are unusable because of them. Many of the educational benefits that the schools want to gain from being connected to the internet are unaccessible because of the limitations NATs place on the types of connections that may be made (and accepted.) The NYC BOE does not have the money or staff to figure out how to properly configure and maintain these devices. But they were put in place most likely because they were presented to the high level admins as an easy way of securing the network. The teachers (as consumers of the technology) have chosen not to use the Internet in the classroom experience because they can't get the same access from the classroom that they are able to receive from AOL at home. --- The use of NATs in home or small office environment must be voluntary by the end user. It is somewhat scary that an end user must now know enough about NATs to ask their proposed ISP whether or not a NAT is going to be used to allocate them an IP address. And if so, be able to instruct the ISP how it should be configured for them. I forsee a day when the use of NATs and the failure by ISPs to disclose their use will result in lawsuits by Ralph Nadar and the Attorney General's offices of several states for fraudulant advertising. --- NATs are workable solutions for the home environment if and only if they are implemented by knowledgeable people or are used by individuals whose range of Internet access is severely limited. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
Randy Bush [EMAIL PROTECTED] writes: what we are talking about is the survival of the Internet. you forgot the news at 11 part Actually, to a large extent, the "internet" as "transparent end to end catanet" *is* dead. It has been dead ever since the average company was forced to use private addressing. Maintaining the pseudo-internet we've got left is costing us a lot of money and manpower, and neither is an unlimited resource. It will make people very happy if we can give them an internet back again. -- Perry Metzger [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
From: Daniel Senie [EMAIL PROTECTED] The counter argument is that for the Home Networking case, which is a HUGE market, it is indeed cheap and easy to use. ... NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. This relates to a thought I've been having over the last couple of days, which is that I recently read that the Internet usage numbers in many large cities in the US (sorry, no idea about the rest of the world, and in any case this point relates to ARIN only) is now at or over 50% of citizens - i.e. in the US, the logistic growth curve for that group (which ought to be the largest possible market segment) has started to tip over. So my question is: I've been hearing that ARIN is the stingiest of the registries when it comes to handing out IPv4 addresses - is there any valid reason for this extreme parsimoniousness (particularly when the plan is to move over to IPv6, so there ought to be no reason for extreme hoarding of IPv4 addresses)? Perhaps a little loosening of the address allocation tap at ARIN, when it comes to allocating addresses for non-home use, could make life substantially easier for the segment where some people are finding NAT making their life difficult? Noel
Re: IP network address assignments/allocations information?
At 04:22 PM 12/7/99 -0500, J. Noel Chiappa wrote: From: Daniel Senie [EMAIL PROTECTED] The counter argument is that for the Home Networking case, which is a HUGE market, it is indeed cheap and easy to use. ... NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. This relates to a thought I've been having over the last couple of days, which is that I recently read that the Internet usage numbers in many large cities in the US (sorry, no idea about the rest of the world, and in any case this point relates to ARIN only) is now at or over 50% of citizens - i.e. in the US, the logistic growth curve for that group (which ought to be the largest possible market segment) has started to tip over. So my question is: I've been hearing that ARIN is the stingiest of the registries when it comes to handing out IPv4 addresses - is there any valid reason for this extreme parsimoniousness (particularly when the plan is to move over to IPv6, so there ought to be no reason for extreme hoarding of IPv4 addresses)? Perhaps a little loosening of the address allocation tap at ARIN, when it comes to allocating addresses for non-home use, could make life substantially easier for the segment where some people are finding NAT making their life difficult? Noel I wouldn't say that ARIN is stingy in how much address space it issues, we allocate whatever an organization (any organization) can justify but they must be able to justify at least a /20 (by whichever allocation/assignment policy applies to them) or they will be referred to their upstream ISP. This isn't done as much for conservation of address space as it is for aggregation of routing table space. We recently lowered our minimum allocation from a /19 to a /20 to allow more organizations to come directly to ARIN for address space and are monitoring the effect on the routing tables to see if we can continue lowering it in the future. Kim
Re: IP network address assignments/allocations information?
Perry Metzger announced: | Actually, to a large extent, the "internet" as "transparent end to end | catanet" *is* dead ^^^ What's a "transparent end to end catanet"? Does that have anything to do with the networks with "hidden" infrastructure in the discussion on translating internet [sic] addresses to local addresses starting towards the bottom of page 5 of IEN 48? Sean. - -- Sean Doran [EMAIL PROTECTED] Mike Padlipsky Fan Club
Re: IP network address assignments/allocations information?
memory is cheap now, so lets loosen those thumb screws ;-) i think we need an automaton to post a few things every few hours to this and the nanog list. it's not the memory. it's the processing power required which is quite non-linear. it's not the memory for the /24s in old b space, it's the horrifying *large* and *long* meltdowns caused by inadvertant leakage of bogus announcements of /24s in old b space randy
Re: IP network address assignments/allocations information?
NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. NAT is a good hammer for a home network if and only if the only purpose of a home network is to allow multiple web clients at home to talk to servers in the outside world. If you want to use a home network to be able to access your devices at home *from* the outside world - e.g. IP telephony, IP fax, instant messaging to your home, IP printing to your home printer from elsewhere, setting your vcr, setting your thermostat so that the house will be warm when you get there, checking the house temperature to see if the air conditioner has died again, taking a peek at the kid you've left home with the babysitter (or by himself) to see that he's okay, investigating the alert you got from your intrusion detection system, personal web server for home or home office - NATs start to look like a pretty poor hammer even for home use. (unless, of course, you think the purpose of hammers is to break things) OTOH, if you combine NAT with 6to4 for home networks, the picture starts to look a bit better. Think of 6to4 as the generic ALG that rids you of the need to have separate ALGs for most of the applications that NAT happens to break. Keith
Re: IP network address assignments/allocations information?
Keith Moore wrote: NAT can be used for a variety of things. Perhaps we can agree that it's a good hammer when the nail is a home network, and concentrate on what to do about the large corporation issue. NAT is a good hammer for a home network if and only if the only purpose of a home network is to allow multiple web clients at home to talk to servers in the outside world. If you want to use a home network to be able to access your devices at home *from* the outside world - e.g. IP telephony, IP fax, instant messaging to your home, IP printing to your home printer from elsewhere, setting your vcr, setting your thermostat so that the house will be warm when you get there, checking the house temperature to see if the air conditioner has died again, taking a peek at the kid you've left home with the babysitter (or by himself) to see that he's okay, investigating the alert you got from your intrusion detection system, personal web server for home or home office - NATs start to look like a pretty poor hammer even for home use. (unless, of course, you think the purpose of hammers is to break things) Sounds to me like at best I'd trade a NAT box with firewalling for a serious firewall. I have ZERO interest in allowing the kinds of things you describe to occur from outside. While you may not mind someone hacking into the microphone on your PC and using it as a bug I am a little less trusting. obviously you have to have some security measures in place before you open up such things to the outside world. but that's an argument for better authentication technology, not for NAT. without the NAT in place I could use IPSEC to authenticate myself and punch a hole through my home firewall; with NAT in place that's just not possible. OTOH, if you combine NAT with 6to4 for home networks, the picture starts to look a bit better. Think of 6to4 as the generic ALG that rids you of the need to have separate ALGs for most of the applications that NAT happens to break. So, will any of our ISP readers go on the record as saying they'll provide users of dialup and DSL/Cable lines to have a large block of addresses each, instead of just a single host address? The way I read the ARIN IPv6 allocation policy, they're going to manage the new space about the same as IPv4 space. Which is to say I don't expect space to be readily available. 1. if IPv6 allocation policies aren't a fair amount more liberal than IPv4 ones in how much address space is doled out, they're broken. there's still a need to aggregate addresses for routing purposes, but there's no need to be stingy about doling them out. 2. at any rate, 6to4 doesn't need IPv6 blocks allocated by ARIN or anybody else; it just needs a single IPv4 address for each customer. i.e. there's already a block of IPv6 addresses allocated for every v4 address and a well defined way to route to such v6 addresses over the v4 Internet. see draft-ietf-ngtrans-6to4-* Keith
Re: IP network address assignments/allocations information?
On Tue, 7 Dec 1999, Keith Moore wrote: OTOH, if you combine NAT with 6to4 for home networks, the picture starts to look a bit better. Think of 6to4 as the generic ALG that rids you of the need to have separate ALGs for most of the applications that NAT happens to break. Mine is not a stand in favor of NATs, let me get that out first :-) However, the arguments against NATs in the home all center around end-to-end connectivity to various devices in the home (light bulbs, toasters, VCRs, thermostats, etc). Is this really the "right" model for that sort of interaction? Personally, my home network (in which every light bulb *will* be on the 'net within the year) is not something I want end-to-end connectivity to. I'm not saying that's the right solution for everyone, but I think it's certainly worth thinking about as we're designing VCR control and LBMP (Light Bulb Management protocol). That is, I think it's important to consider that folks (via their vendors) will want to deploy ALGs at the boundary of the house, NAT or not. I know I will be, even after the internal v6 infrastructure meets up with the rest of the world in the far flung future. I don't think NATs are architecturally "correct", but I think they're teaching us an important lesson about the (initially valid) assumptions about end to end connectivity. Even after we eradicate NATs through wholesale migration to v6 (optimist hat on), the paranoid will still deploy ALGs on their firewalls to mediate access to those globally routable lightbulb and security camera addresses. After all, I wouldn't want the world getting illicit shots of me in my underwear in the evenings. Well, perhaps it's the world that wouldn't want to be getting those shots, but you get my point... -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "There are plenty of things out there that people should be offended about. Put your indignation into some more productive and appropriate fight." - Larry Rosensweig in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html
Re: IP network address assignments/allocations information?
On 7 Dec 1999, Perry E. Metzger wrote: Tripp Lilley [EMAIL PROTECTED] writes: Is this really the "right" model for that sort of interaction? Yes. I don't want to invent fifteen thousand different protocols to handle things. IP already does what I need most of the time. Perhaps I wasn't clear... IP (v4 or v6 or what have you) is a fine way of determining the end points of the communication. But at higher levels (MEGACO, SIP, LBMP, etc.), I believe it makes sense to allow in the protocol design that people might want to consolidate funcionality in an ALG (more below) I'm not sure that's the right model, actually. IP addresses are too easy to forge. The right way to stop people from doing that sort of thing is to deploy end to end security protocols that strongly authenticate both ends. Realistically, in the home environment (which is quite specifically the domain I'm constraining these statements to, even though they might have broader applicability), it's unreasonable to expect that every light bulb (light fixture) is going to carry the silicon to handle authentication (and/or encryption). I think it makes sense to consider a boundary (firewall+ALG) that defines a "trusted zone" within the house, establishes ACLs for a given "connection", be it a tunnel or otherwise, defined by an authentication event, and mediates the activity over that connection as long as it's active. Treating each and every action into that trusted zone as a separate request, carrying separate overhead for connection setup and teardown (over the WAN), and separate overhad for authentication and encryption puts us in the same boat as HTTP/1.0. I'm not saying we should consider anything other than IP to establish the desired endpoints of the given transacion. I'm not saying we should try to hide topology and addressing behind a NAT. I'm saying that even *with* a connection that's end-to-end for the purposes of designating participants, we might want to consider that someone in the middle will be mediating the conversation, acting on behalf of one or both participants. An example to wit: I want to be able to plug my Extend-A-Home 2000 (tm) intelligent brick into the ethernet jack in my hotel room, then unpack all the rest of my goodies (portable printer, portable scanner, wireless IP phone, Palm Connected Organizer(tm), MP3 player, etc.) and have them "just work". Now, I realize that all of this can be accomplished through a combination of DHCP, DDNS, and IP Mobility. But that requires an awful lot of complexity in each device, when that complexity *could* be hidden inside the Extend-A-Home 2000 (tm). I plug it in and *voila*, my hotel room is an extension of my home. All of my permissions into my home remain intact (with only an authentication exchange between the Extend-A-Home 2000 and the Home-Weiller 2000 Border Establishment Unit(tm)). You also have to consider that just because IP is the "right" answer doesn't mean it's what will end up in the stacks of all of these micro devices (especially light bulbs). There will be gateways and proxies for LON and CANbus and X-10 and so forth for a while to come, possibly forever. All I'm saying is that taking ALGs into account for reasons *other* than NAT doesn't seem like such a bad idea as we're doing new work. -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "There are plenty of things out there that people should be offended about. Put your indignation into some more productive and appropriate fight." - Larry Rosensweig in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html
Re: IP network address assignments/allocations information?
Is this really the "right" model for that sort of interaction? Personally, my home network (in which every light bulb *will* be on the 'net within the year) is not something I want end-to-end connectivity to. why not? seems like if you want your light bulbs to be independently addressable or pollable (can't wait for the SNMP lightbulb MIB!) you want the ability to talk to them directly. OTOH, if for the specific case of light bulbs you want some sort of "light management system", then maybe you want to talk to that light management system rather than to the individual light bulbs. the point is, even though you might want some local resource managers to mediate the use of light bulbs, whatever, that doesn't mean that you want to block all outside connectivity to every device in your home. if you have to have an ALG for everything you want to control from outside that is going to impose a serious barrier to the kinds of controllable devices you can have in your home - because you won't be able to control it unless your NAT supports the right ALG for each device you want to use. and it's downright silly to have a wireless PDA (say a palm vii or a pdq phone) and not be able to use it to talk to your devices within the home just because your PDA and your home are on opposite sides of a NAT.
Re: IP network address assignments/allocations information?
I think it makes sense to consider a boundary (firewall+ALG) that defines a "trusted zone" within the house, establishes ACLs for a given "connection", be it a tunnel or otherwise, defined by an authentication event, and mediates the activity over that connection as long as it's active. you're confusing trust boundaries with network topology. trust boundaries don't follow network topology even today, or you have to do a fair amount of work to make them do so. they're even less likely to follow network topology in the future when a significant number of the devices we want to talk to are running wireless IP. and just because I have multiple devices in my home doesn't mean that I trust my (roommate, spouse, kid, babysitter, houseguest, burglar, landlord, friendly neighborhood cop) to have net access to everything in my home merely by having physical presence there. nor do I want to have to run separate protocols to access devices on my home network than for the same kinds of devices located in other environments. Keith
Re: IP network address assignments/allocations information?
At 10:05 PM 12/7/99 -0500, Perry E. Metzger wrote: Tripp Lilley [EMAIL PROTECTED] writes: I don't think NATs are architecturally "correct", but I think they're teaching us an important lesson about the (initially valid) assumptions about end to end connectivity. Even after we eradicate NATs through wholesale migration to v6 (optimist hat on), the paranoid will still deploy ALGs on their firewalls to mediate access to those globally routable lightbulb and security camera addresses. I'm not sure that's the right model, actually. IP addresses are too easy to forge. The right way to stop people from doing that sort of thing is to deploy end to end security protocols that strongly authenticate both ends. Anythink mankind can lock, mankind can unlock. You will never get rid of firewalls. At least not in our lifetimes.
Re: IP network address assignments/allocations information?
I'm not advocating one technology over another. I am claiming that in the IPV4/Private/Public/NAT world, a bigger pool of Private space would be a big help to many organizations. I think this is a fine idea. What we need is to reserve enough private address space so that each organization can have its own chunk of private address space. That way, organizations won't have to fiddle with their mapping tables to avoid conflicts! In fact, I think we should reserve the entire remainder of IPv4 address space, and most of IPv6 address space, for use as private address space. Of course, for the sake of routing scalability it will be necessary to assign most of this private address space out of larger chunks that are assigned to ISPs, but except for that little detail, it sounds like a wonderful idea! (end sarcasm) seriously, the only way you can have private address space large enough to map all of the other private address spaces (that you wish to talk to) into your private address space, is to reserve a portion of your own private address space that is large enough for all of the other private address spaces (that you wish to talk to) combined. problem is, everyone else's private address space is potentially as large as your own. making the private address space larger won't solve that problem. it might give you a few months' breathing room, but eventually you end up having to limit the amount of address space that any organization can use, so that there's room to map it into everyone else's address space. once you do that you might as well just assign a chunk of address space to each organization. and for that we need IPv6. Keith
Re: IP network address assignments/allocations information?
Perry, Jon Crowcroft [EMAIL PROTECTED] writes: Having said that, I ask you: What do you foresee as a realistic IPv6 transition plan? Dual stacks? I don't see it happening, to tell you the truth. (Maybe this 6-in-4 stuff will actually help here.) well, how about we just start to turn it on in some routers? - it works in most host OSs now, dual stack, just fine. the value of the net is the square of the number of people connected - NAT is a square root function. NAT has actually created a simple transition plan for us. I'd say at this point that 95% of the corporate networks in the U.S. use private addressing and a NAT or proxy box at the border. Switching from this to using v6 internally with a v6 to v4 NAT/proxy at the border for communicating with v4 is trivial -- since they don't have globally routable addresses now, they won't be hurt by the switch. As more and more people switch to this configuration, they'll start finding themselves talking to more and more things over the net natively, and fewer and fewer through the translator. Suddenly, they'll discover they *do* have globally routable addresses again, just like we did in the old days before net 10 was turned into the universal addressing ghetto. This could go as you described *until* these folks would start to move from one provider to another, and therefore will be faced with the need to renumber. At that point NAT could become quite an attractive alternative from cost/benefit point of view again. And now these folks will be back to where they've been with IPv4, but but with the extra cost of IPv4 to IPv6 transition. Yakov. P.S. While one could argue that renumbering with IPv6 could be made simpler than with IPv4, what one really needs to compare is renumbering with IPv6 vs renumbering with NAT.
Re: IP network address assignments/allocations information?
In message [EMAIL PROTECTED], Yakov Rekhter typed: Consider an alternative where the client decides to use IPv6. Granted, the client could get enough IPv6 addresses for all purposes, regardless of whether these purposes essential or not. But then in order for that client to communicate with the rest of the folks, the client would likely to use NAT (as the rest of the folks would still use IPv4). its economics - if one large client uses IPv6, then so will others eventually as its cheaper for all of them colelctively than for them to go on using NATs. the cost of using NAT wouldn't go away. But in addition, this alternative would cause the client to swallow the cost of transition from IPv4 to IPv6 in its infrastructure. right - the problem is gettng the FIRST person to go - clearly a PROVIDER could consider swallowing the cost (i.e. pay cisco to implement, and debug a deployed IPv6 backbone and then chase customer problems) - why? because in the LONG run there's more subscribers selling content, doing busienss in a fully IP (v6) connected net than on a NAT disconnect, and so there's more money for the provider btw, i think the address space stuff for subscribers using NATs is often (not always) hokum - its mostly that they can't be bothered to design a decent addressing architecture for their intranets. cheers jon
Re: IP network address assignments/allocations information?
btw, i think the address space stuff for subscribers using NATs is often (not always) hokum - its mostly that they can't be bothered to design a decent addressing architecture for their intranets. cheers jon Oh, I think that there are lots of good engineers out there who do a great job of designing decent addressing architectures for their networks. Now if the darn things would just stay within the design constraints over time, there would not be a problem. Trouble is, those pesky users keep thinking up new things to do with the network, violating design assumptions. Makes the addressing architects life a living hell... (insert a quick overview of the evolution of the IPv4 addressing architecture here...) Still, I do think a basic NAT design philosophy is one of "withdraw into my own little world, protecting me from dealing w/ the troubles outside". -- --bill
Re: IP network address assignments/allocations information?
Ian King [EMAIL PROTECTED] writes: But then again, I would expect that a large corporation would see the need to own a large address space, rather than attempting to "pseudo-expand" its address space through the use of NAT. You are assuming they could get such a space. They can't. No one can if you aren't a provider. The registries will simply tell you to go off in the corner and use private address space instead. The situation right now is really horrible. People are pretending it isn't, but the pretense really has to end. The End to End model isn't just a "nice idea" -- its actually needed for people to manage and maintain networks cost effectively. Its effectively dead a the moment, and frankly, I'd like the internet back again, instead of this kludge we're using instead these days. Perry
Re: IP network address assignments/allocations information?
From: "Perry E. Metzger" [EMAIL PROTECTED] When you've been awakened in the middle of the night every night for a week, because the NAT rules to deal with the fact that you have several intercommunicating networks all of which think they're 10.0.0.0/8 ... Anyone out there who thinks NAT works well and is harmless is not familiar Perry, I'm curious about the technical aspects of the problems you're seeing, in particular: Are the problems you are seeing due to i) the need for NAT boxes to grope around in packets, ii) the fact that hosts don't have permanent, globally visible internetwork-level 'names', or iii) something else (e.g. complex configuration management)? The reason I ask is twofold. First, there is an alternative technology being proposed for local addresses in IPv4, RSIP, which should avoid i), but still leaves us with ii) and iii). So, to the extent the problems you are seeing are ii) and iii) we're still kind of stuck, even if RSIP happens. To the extent that the problem is really i), though, RSIP might alleviate the situation. Second, when examining the transition technologies for deployment of the proposed new internetwork layer, I've been pondering the problem of an non-upgraded host trying to talk to an upgraded host with an address which is only expressible in the new internetwork layer. The proposed transition technologies I've examined (i.e. NAT-PT, AIIH, and SIIT) *all* seem to have (at least as far as the IPv4 world is concerned) characteristic ii) - in that as far as non-upgraded hosts are concerned, upgraded hosts using those schemes don't have a permanent 'name' at the internetwork layer. So I'd really be curious to know a little more about the "forest-level" nature of the problems you're seeing out there - I think it will be very insightful in considering a number of potential forward directions. Noel
Re: IP network address assignments/allocations information?
"Perry E. Metzger" wrote: BTW, I fully agree with those who contend that v6 does not solve the route agregation problems we have in v4. In itself, no; but getting people who have old non-aggregatable addresses to transition to v6 will give them the chance to get aggregatable addresses, won't it? -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |"Time is money, and price is information." | |[EMAIL PROTECTED]|--Russ Nelson| \==/
Re: IP network address assignments/allocations information?
John Stracke wrote: "Perry E. Metzger" wrote: BTW, I fully agree with those who contend that v6 does not solve the route agregation problems we have in v4. In itself, no; but getting people who have old non-aggregatable addresses to transition to v6 will give them the chance to get aggregatable addresses, won't it? Perhaps. It then trades something else off. There are legitimate reasons to NOT have aggregatable addresses. Some companies actually like multihoming, as a way to keep their services operational in the face of one network provider melting. Aggregation isn't the goal of customers, reliability is. Having multiple connections to one ISP is not considered sufficient, either. We have adopted a world view where only ISPs are worthy of being multi-homed, and everyone else must aggregate through a single ISP. There's something Perry may be alluding to (or not). Many companies create PRIVATE internetworking links among themselves for handling sensitive data. These require unique addressing. IPv6 has, to date, not been an option for this use. Two reasons: 1. The registries were not, until recently, handing out IPv6 addresses, and 2. The registries are using the same kinds of rules as for IPv4 in that addresses are handed out to ISPs who then hand them to companies. The problem with this is that if you never intended to route the addresses on the public net anyway, you won't be seen as worthy by the ISPs, or the registries. I have been thinking for a while that it'd be useful for IANA to set aside a class A block for a new registry. This one would provide very small blocks of addresses, for private inter-corporate use only, to anyone willing to pay. This would provide a guarantee to users that the addresses they get ARE unique, and will work. It's kind of like RFC 1918 addresses, but with a block set aside for private interconnects. Clearly it's too late to do this with the blocks presently in RFC 1918, though. Take this same idea, and replace that class A with a big prefix in IPv6 space and perhaps the folks doing private interconnects will help fund the development of IPv6 equipment and updated applications. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: IP network address assignments/allocations information?
Daniel Senie wrote: Some folks are doing this for dialups too. It's the model for "home networking" today. Will ISPs be willing to assign a block of addresses in the future to home networks? Today, they are not, because they want to make that a premium service. However, one day, they may realize that the reason their customers aren't buying that premium service is that they don't need it; they're using NATs instead. If IPv6 becomes common, and ISPs don't have to hoard addresses, offering subnets as part of the basic service could become a good point of competition. -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |"She gets kidnapped. He gets killed. But it | |[EMAIL PROTECTED]|turns out okay." -- _Princess Bride_ poster | \==/
RE: IP network address assignments/allocations information?
Daniel, Surely you cannot conceive a time when the IP address' are the domain of everyone. The growth of the Internet / Networking within the last 5 years shows you that our current addressing schema is inadequate for the future demand, if you extrapolate the current growth in line the growth in births and longevity of folks then this says in itself that we can expect an addressing schema aimed at the "man on the street" and another one for business and a third for the backbone and a fourth for the hell of it. A single IP address' combined with the mobility factor will make it a very attractive future, why not get involved and start the WG for it now. The future is not that far away. Regards Mark Paton CEO/DIR. Internet Network Eng Mercury Network Systems Limited +44 585 649051 http://www.mnsl.org "Mercury Network Systems - The Unstoppable Force" This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information if you are not, or suspect that you are not, the named addressee or the person responsible for delivering the message to the named addressee, please telephone us immediately. Please note that we cannot guarantee that this message or any attachment is virus free or has not been intercepted and amended. The views of the author may not necessarily reflect those of the Company. -Original Message- From: Daniel Senie [mailto:[EMAIL PROTECTED]] Sent: 03 December 1999 21:10 To: Perry E. Metzger Cc: J. Noel Chiappa; [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? "Perry E. Metzger" wrote: If you mean RSIP, RSIP is even further from deployment than v6. Indeed, I'd say that RSIP is a clever but utterly dead end idea. I too would rather see effort put into IPv6... if it's going to happen, let's get going, though... it's been in the oven too long. There's one scenario about IPv6 which worries me, and which may well make RSIP and NAT in a pure IPv6 world a reality. Today we have LOTS of folks using NAT(NAPT really) for connecting to cable modems and DSL lines. Some folks are doing this for dialups too. It's the model for "home networking" today. Will ISPs be willing to assign a block of addresses in the future to home networks? What does that mean when the access is a dialup? Sooner or later, we'll have providers handing out a single IPv6 address to any home user customer, just as is done today with IPv4 addresses. It is for this user population that RSIP will likely be a real issue. One of the things to think about is that while there is use of various NAT flavors in corporate environments, it is or will be nearly ubiquitous in the home market. Linux and Windows both include credible, functional NAPT solutions today. Is it ugly? Sure. Is there any chance it'll stop being attractive to the home user? Unlikely. -- -- --- Daniel Senie [EMAIL PROTECTED] Amaranth Networks Inc. http://www.amaranthnetworks.com BEGIN:VCARD VERSION:2.1 N:Paton;Mark.;J.S;; FN:Mark. J.S Paton ORG:Mnsl;Consultancy TITLE:Network Design / Support TEL;WORK;VOICE:+44 0585 649051 TEL;CELL;VOICE:+44 (0585) 649051 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Basingstoke;Willow Cottage=0D=0AReading Road;Mattingley;Hampshire;RG27 8JU;= United Kingdom LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Basingstoke=0D=0AWillow Cottage=0D=0AReading Road=0D=0AMattingley, Hampshire= RG27 8JU=0D=0AUnited Kingdom URL: URL:http://www.mnsl.org EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19990422T133901Z END:VCARD
Re: IP network address assignments/allocations information?
In message [EMAIL PROTECTED], "J. Noel Chiappa" typed: The various approaches to growing the Internet (IPv6, NAT's, etc) all have costs and benefits - yes, but propviders don't actually ASK the users what the COST is of a NAT the BT ADSL trial in london uses NATs and all the folks i know who are what BT might call "advanced" users (i.e. people who want to export files on web servers, use multicast apps etc), find it a REAL PAIN in the backside comapred to their old school/university 'always on' access but at no point in any of the market research on the trial users did the provider bother asking about this, so they remain cluelessas do many NAT Proponents. cheers jon
Re: IP network address assignments/allocations information?
Brian E Carpenter [EMAIL PROTECTED] writes: 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. I hate to start a flame war, but Brian is absolutely right. I have clients spending gargantuan amounts of money dealing with layer upon layer of NATs because of this. Some people believe that "we aren't running out of address space" but the fact is that we've already run out. It just isn't available for many essential purposes. Perry
Re: IP network address assignments/allocations information?
"Fleischman, Eric W" [EMAIL PROTECTED] writes: 1) If we effectively ran out of addresses when RFC 1597 was published, has running out of addresses hurt us in any way? I count "hurt" in dollars. The answer is yes. A client of mine just spent millions of dollars because of our current broken pseudo-internet in which everyone has to use private addressing 90% of the time. None of this money would have been spent if end to end addressing had been possible. This expenditure doesn't count the constant maintenance nightmares that layers of NATs have caused this particular client, and the expenses coming from that. Money is a nice, quantifiable kind of pain. From what I can tell, the pain levels are very high. When your NAT nesting turns your simple network restructuring into a multi-million dollar game of pick-up-sticks, you're past the point where its ignorable. Of course, as one provider told me at the DC IETF, in literally these words, "NAT works just fine. Besides, customers are mostly there just to spend money anyway." Perry
Re: IP network address assignments/allocations information?
Ian King [EMAIL PROTECTED] writes: 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. You aren't a large corporation trying to deal with huge numbers of private customer connections running over IP. When you've been awakened in the middle of the night every night for a week, because the NAT rules to deal with the fact that you have several intercommunicating networks all of which think they're 10.0.0.0/8 have become so complex no human can really remember them all any more, you'd experience what many of the rest of us feel week after week. The lack in question is a lack of sleep. Anyone out there who thinks NAT works well and is harmless is not familiar with how the brave new world of pseudo-internetworking works. "Oh, no. When we moved the mail hub for the client access networks in location A, it seems no one remembered to update the NAT rules for the systems in location C. That's why the help desk has been inundated for three days..." Perry
RE: IP network address assignments/allocations information?
So what you're saying is that NAT doesn't scale well, at least from a management perspective. I'm not surprised. Again, I would suggest that NAT is not a silver bullet, but rather a useful "hack" in some circumstances. The situation you describe appears to be demonstrative of its limitations. (BTW, one time I forgot to change the NAT rules when I moved my sendmail server on my four-machine network, and) :-) But then again, I would expect that a large corporation would see the need to own a large address space, rather than attempting to "pseudo-expand" its address space through the use of NAT. (My company, with a fairly substantial intranet, uses proxying as its internal solution.) Maybe I don't understand the usage you're describing, but the point I keep trying to make is that NAT isn't evil; that doesn't mean it solves every problem, OR that it should be re-engineered so that it does. -- Ian -Original Message- From: Perry E. Metzger [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 02, 1999 2:54 PM To: Ian King Cc: 'Richard Shockey'; Keith Moore; [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? Ian King [EMAIL PROTECTED] writes: 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. You aren't a large corporation trying to deal with huge numbers of private customer connections running over IP. When you've been awakened in the middle of the night every night for a week, because the NAT rules to deal with the fact that you have several intercommunicating networks all of which think they're 10.0.0.0/8 have become so complex no human can really remember them all any more, you'd experience what many of the rest of us feel week after week. The lack in question is a lack of sleep. Anyone out there who thinks NAT works well and is harmless is not familiar with how the brave new world of pseudo-internetworking works. "Oh, no. When we moved the mail hub for the client access networks in location A, it seems no one remembered to update the NAT rules for the systems in location C. That's why the help desk has been inundated for three days..." Perry
Re: IP network address assignments/allocations information?
Perry, Brian E Carpenter [EMAIL PROTECTED] writes: 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. I hate to start a flame war, but Brian is absolutely right. I have clients spending gargantuan amounts of money dealing with layer upon layer of NATs because of this. Some people believe that "we aren't running out of address space" but the fact is that we've already run out. It just isn't available for many essential purposes. Consider an alternative where the client decides to use IPv6. Granted, the client could get enough IPv6 addresses for all purposes, regardless of whether these purposes essential or not. But then in order for that client to communicate with the rest of the folks, the client would likely to use NAT (as the rest of the folks would still use IPv4). So, the cost of using NAT wouldn't go away. But in addition, this alternative would cause the client to swallow the cost of transition from IPv4 to IPv6 in its infrastructure. Yakov.
Re: IP network address assignments/allocations information?
John, You are absolutely right. Time should be spent developing "good algorithms" which is common "good architecture". What NAT does is just another form of the same thing that X.25, ATM, and MPLS do with different identifiers. It is not bad algorithm there nor bad architecture. This is the second time you've said this, the first time I just cringed. I would tend to agree. As I have said elsewhere, NATs in and of themselves do nothing wrong. They are doing things within the Internet/Network Layer that are perfectly legal. (In essence, they are treating the network address in much the same way that X.25, ATM, and MPLS treat their addresses.) I find this assertion to be amazing. It's perfectly legal for a device to modify any field in the IP header if it so desires? Do you also agree that it's legal to modify the IP ident field (and potentially break fragmentation?) What about the length field, or flags field, etc., etc.?? Also, NATs have to modify the TCP/UDP checksum, i.e., look inside the upper layer protocol it is carrying and modify the payload. This is also not "bad architecture"? The problem is that applications lacking an "application address space" are using the Network address space inappropriately. IMO, this is a widespread oversimplification of the situation. If you want to point fingers, TCP is also broken from the perspective of NAT, because transport layer addresses are formed from both IP addresses and port numbers. It's not just applications sending addresses in payloads that "are broken", it's a key aspect of the basic TCP (and UDP) design. Sure, there are folks that say "fix TCP". But this is also naive. There is a good reason why TCP is designed this way. Having transport addresses be completely independent of the IP address in the IP header requires having some way of mapping from one name space (e.g., the TCP transport identifier of a service one wants to communicate with) to the IP address (so that the TCP header can be put into an IP packet and sent to the actual destination). Although folks have talked about doing something like this for years, it has not been done (i.e., where is a document showing how it can be done?) and folks have argued endlessly about whether building such a system is feasible or really solves the problem as opposed to just creating a new (hard) problem elsewhere that then needs solving. Thomas
Application name space and ASN.1 (Re: IP network address assignments/allocations information?)
At 22:52 30.11.99 -0500, John Day wrote: 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? For those who missed the previous round. at the time ASN.1, X.400 and X.500 were defined, ISO/ITU (mostly ISO) also defined the concept of an "application" to be (..) (that's about the right level of precision) that you could address by using an "application entity title" or similar entity. Somehow this idea never turned into anything that real products use for real operations, but you sometimes stumble across the relics of the idea here and there. Naming applications something different from host:port would be nice. But we haven't managed to do it yet. Harald A -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
* * 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. * * Unfortunately the existing Internet is no longer an implementaion * of the existing Internet architecture. That's why we have a problem. * * Brian * Brian, I don't disagree with you. I was only trying to counter what seemed to me a bogus appeal to the abstract principles of the Internet architecture. Bob
Re: IP network address assignments/allocations information?
At 11:50 -0500 12/1/99, Brian E Carpenter wrote: Bob, Bob Braden wrote: * * 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. Unfortunately the existing Internet is no longer an implementaion of the existing Internet architecture. That's why we have a problem. That may be the best observation I have seen on this topic! Take care, John
Re: Application name space and ASN.1 (Re: IP network address assignments/allocations information?)
At 7:06 -0500 12/1/99, Harald Tveit Alvestrand wrote: At 22:52 30.11.99 -0500, John Day wrote: 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? For those who missed the previous round. at the time ASN.1, X.400 and X.500 were defined, ISO/ITU (mostly ISO) also defined the concept of an "application" to be (..) (that's about the right level of precision) that you could address by using an "application entity title" or similar entity. Interesting. So someone else picked up on early ARPANet/Ethernet ideas and tried to use them. Somehow this idea never turned into anything that real products use for real operations, but you sometimes stumble across the relics of the idea here and there. Does this mean that if someone else tries to use an idea in their environment from our environment that then makes it a bad idea for us to use? I still don't understand why you even brought up this line of discussion. I don't see its relevance at all. Shoch's paper laid down some basic concepts in naming and addressing and he did it very early on. I don't see that they have been contradicted by anything that has transpired in the meantime. So what is your problem with Shoch's paper? Naming applications something different from host:port would be nice. But we haven't managed to do it yet. Maybe we should. It might make a number of things easier. Take care, John
Re: IP network address assignments/allocations information?
John Day wrote: Cmon, surely you can come up with a better counterargument than that! ;-)) I certainly could. If it is architecturally acceptable for those protocols to rewrite the address field at every hop, why shouldn't it be for IP? How does it differ? Basically a NAT is doing what an ATM switch does. How does an MPLS tag differ? Here is the difference between NAT and the other things you mention. The only changes to the IP header and encapsulated data should be the TTL and fragmentation information. Granted ATM chops the packet into small cells, but when its put back together the packet looks the same. This cannot be said of NAT. But it would be a big step to solving the problem. However, there are so many special cases now of people doing strange things with IP addresses that they shouldn't be doing that there may not be anyway out of the problem. Ok, here is where the rubber meets the road. What is "the problem"? My guess is that you think the protocols/applications are broke, or architecturally unsound. I think the problem is that NAT became "necessary". I am well aware of the issues, but I did want to push back on people who see no problem with applications exchanging IP-addresses. Is there a constraint/expectation that these applications/protocols run on something other than IP? Is it a requirement that when (if) the switch is made to IPv6, that all IPv4 applications will work over IPv6, and even better yet work across an IPv4/IPv6 "converter"? While these would all be nice things to have, are they design requirements? Is the goal to have a stackable streams-like system where I can slide in/out or replace "modules" letting me (in theory) run any application using any transport over any physical medium? It's a nice idea, but certainly brings with it lots of complexity. My personal opinion is that the IETF's goals essentially boil down to "IP on everything". Unfortunately, this means if IP changes, everything much change with it. Just as IP's predecessor is gone, so would vanish old versions of IP. This of course has its own problems, but I think identifies (at least for some) the current mindset. If the IETF has to identify and specify the entire behavior from user interface to bit order on the wire, their charter needs to be expanded. Tony
Re: IP network address assignments/allocations information?
Everyone, this conversation isn't really going to be very productive. The people who like A aren't about to start liking B, and vice versa. (And then there are the people who don't like either - but they aren't going to change their minds either! :-) So discussion on this point is not going to be very productive. The various approaches to growing the Internet (IPv6, NAT's, etc) all have costs and benefits - but each differing costs and benefits. In a system as large as the Internet, it is to be expected that some people will evaluate the costs and benefits, and decide that for their particular situation, option A is to be preferred. Others will prefer option B. In the end, if a single approach does become the predominant one, it will be the market that decides (as individuals look at the costs and benefits in their individual cases), not the IETF. The IETF can't do a lot to influence this outcome - we don't have a police force, nor an army, so we can't stop someone from using A, or force them to use B. The IETF has always done much better at *designing* protocols than it has done at *choosing* protocols. Let's stick to designing, and stop arguing about which one to pick, eh? Noel
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 |
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
Re: IP network address assignments/allocations information?
Eric, "Fleischman, Eric W" wrote: 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? I believe so, as discussed in draft-carpenter-transparency-04.txt draft-ietf-iab-ntwlyrws-over-01.txt draft-iab-nat-implications-04.txt draft-ietf-nat-protocol-complications-01.txt among others. 2) Originally we had anticipated using IPv6 to save us from IPv4 address depletion. What's the status of IPv6? Pretty good, in terms of standards and preliminary code. Only just starting, in terms of deployment. How does IPv6 traffic compare in volume with IPv4 traffic? Negligible so far. Do non-IPv6-supporting vendors (e.g., Microsoft) have plans to eventually support IPv6? Ask them. 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? It's entirely possible, but the answer depends on which curve you choose to fit to the data. That's why the answers given at the July IAB workshop ranged from 2 to 20 years. But whatever the answer is, it obscures the real problems described in the above documents. Brian -- 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?
As the original instigator of this thread, I want to thank everyone for their assistance, as well as for the thought-provoking discussions that have ensued. They have all been very helpful. As a sort of follow-on question, I've been scrutinizing the delegations listed here: http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space One of the things I'm interested in is the geographic distribution of allocated IPv4 space. I realize that parts of the former Class B/Class space was assigned to non-US networks prior to RIPE-NCC and APNIC being established to assign addresses; however, since then, peices of IPv4 address space have been delegated to the RIRs. Some of those chunks are explicitly identified, e.g.: 061/8 APNIC - Pacific Rim However, there are two entries on the table: 128-191/8 Various Registries 192/8 Various Registries - MultiRegional that are more puzzling. How can I figure out which registries have gotten a piece of these particular chunks? Is there an online resource tucked away somewhere that lists all this? I'm not interested so much in how much of these allocations have been used as in which registries now control them. Any pointers are again much appreciated. Thanks! -pl +-+ | Pete Loshinhttp://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-+
Re: IP network address assignments/allocations information?
Steve Hultquist wrote: ... I also think that it's interesting to consider that security concerns are the other primary reason for use of NAT. As had been repeatedly pointed out, this is a totally bogus argument for NAT. Filtering routers were around long before NAT, and protect systems against intrusion just as well as NAT. Brian
Re: IP network address assignments/allocations information?
At 07:02 PM 11/29/1999 -0500, Keith Moore wrote: Many of the people who have deployed NATs are responding directly to the address scarcity (and resultant cost). If you consider that many ISPs now have different pricing models for multiple IP addresses than they do for a single (regardless of bandwidth used), it isn't surprising. no, not surprising (and in fact some people predicted it), but it is surely unfortunate. I can personally testify to the above comments. Consider...we are all IP professionals ...so we'd like to occasionally play with all of the wonderful toys we've built...at home. Our fathers stuck their heads under the hoods of cars or played with short wave radios...we play with IP. Now try and ask your friendly neighborhood DSL or Cable Modem provider about getting a nice chunk of IP addresses. Well we all know what DSL really means ..._D_riveway _S_ite _L_iaison or the modern version of "Who on first?". You want to run a web server, DNS (from home?) IPP printer accessible printer ( DUH what's IPP?), SIP phone .. pick your application. To the service providers the request for IP addresses is some sort of strange signal that you're running a eCommerce site from home or worse a Game/Porn site. Something that they believe they should charge more money for. The path of least resistance is just install a NAT. The market for NAT device/software products are being driven by in part the lack of IP4 numbers but certainly the lack of knowledge, marketing skills or just plain greed of the ISP community. Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail IFAX : [EMAIL PROTECTED] GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464
RE: IP network address assignments/allocations information?
Yes, my ISP is charging me for my DNS entry -- a static entry made once in a zone file, but I'm paying monthly to have a domain name! Never mind that I don't use their mail server or Web page service or DNS server 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. 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 -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED]] Sent: Monday, November 29, 1999 8:00 PM To: Keith Moore Cc: [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? At 07:02 PM 11/29/1999 -0500, Keith Moore wrote: Many of the people who have deployed NATs are responding directly to the address scarcity (and resultant cost). If you consider that many ISPs now have different pricing models for multiple IP addresses than they do for a single (regardless of bandwidth used), it isn't surprising. no, not surprising (and in fact some people predicted it), but it is surely unfortunate. I can personally testify to the above comments. Consider...we are all IP professionals ...so we'd like to occasionally play with all of the wonderful toys we've built...at home. Our fathers stuck their heads under the hoods of cars or played with short wave radios...we play with IP. Now try and ask your friendly neighborhood DSL or Cable Modem provider about getting a nice chunk of IP addresses. Well we all know what DSL really means ..._D_riveway _S_ite _L_iaison or the modern version of "Who on first?". You want to run a web server, DNS (from home?) IPP printer accessible printer ( DUH what's IPP?), SIP phone .. pick your application. To the service providers the request for IP addresses is some sort of strange signal that you're running a eCommerce site from home or worse a Game/Porn site. Something that they believe they should charge more money for. The path of least resistance is just install a NAT. The market for NAT device/software products are being driven by in part the lack of IP4 numbers but certainly the lack of knowledge, marketing skills or just plain greed of the ISP community. Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail IFAX : [EMAIL PROTECTED] GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464
Re: IP network address assignments/allocations information?
At 15:35 99-11-26 -0600, Brian E Carpenter wrote: 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 sorry, many many many thousands of sites. for example, I would fairly guess these days that 75% of sites use private address space. I would say that 90% of the networks I've seen at our clients sites are using private address space. I would say that now, a lot of global ipv4 address space is used mostly for the outside interfaces of sites: i.e. firewall external address, web/smtp/... external servers. Marc. 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 --- Marc Blanchet | [EMAIL PROTECTED] Viagénie inc. | http://www.viagenie.qc.ca 2875 boul. Laurier, suite 300 | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-266-5539 Canada, G1V 2M2 | radio: VA2-JAZ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org
IP network address assignments/allocations information?
Hi. I'm trying to track down some information about IP network address allocations/assignments. Specifically, I'm looking for some reasonable estimate of the number/proportion of Class B/Class C networks that have been assigned out of the entire amount possible. The allocation of address space to registries (and Class A assignments) is available at: http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space And I know that the IMRs (Internet Monthly Reports) used to contain monthly updates of network assignments by class--but that series ended (didn't it?) and of the ones I've read, some are missing those figures. So that's not a practical solution. I'm pretty sure that I've seen figures about the total number of Class B/Class C networks assigned (and/or allocated to ISPs for reassignment). I'd be very grateful if someone could point me in the right direction. Thank you! -pl +-+ | Pete Loshinhttp://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-+
Re: IP network address assignments/allocations information?
Pete Loshin wrote: Hi. I'm trying to track down some information about IP network address allocations/assignments. Specifically, I'm looking for some reasonable estimate of the number/proportion of Class B/Class C networks that have been assigned out of the entire amount possible. The allocation of address space to registries (and Class A assignments) is available at: http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space Thank you! -pl http://ipv4space.TopLayer.Com/ has some information -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Re: IP network address assignments/allocations information?
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?
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". the original question was not whether address panic was justified. it asked for data on assignments/allocations. these are real measurable numbers which should be easily available, not a platform for political or social grandstanding. randy
