Functionality needed in NATs (Re: [midcom] WG scope/deliverables)
At 16:36 15/02/2001 -0800, Bernard D. Aboba wrote: Today, NAT penetration among consumers isn't very high because networked multi-PC homes are relatively rare. However, as multiple device homes proliferate along with home networking, I would expect the majority of consumer PCs to be behind NATs by 2005. Unless we start thinking now about the minimal NAT functionality necessary to deploy IPv6, and get this into shipping NATs soon, we will face very substantial barriers to IPv6 adoption down the road. I think (as far as I can think :-) that the minimum functionality needed to deploy (say) 6to4 behind a NAT is the ability to configure it to pass all packets carrying 6to4 traffic to a separate box. Other scenarios have other requirements. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: NAT natural example, Re: [midcom] WG scope/deliverables
[I've taken the bulk of my response to Ed's last reply to private mail, since I assume few here are interested in tedious arguments about exactly how the Internet is analogous to the postal system, but I'll just make his one public observation:] At 9:45 PM -0800 2/15/01, Ed Gerck wrote: I agree that you can define many different analogies, from that example. But, as above, if you consider the way that information is received then a NAT box is IMO one valid analogy for reception because it satisfies the functionality observed in a NAT box when receiving packets. Your postal example doesn't entail the modification of an address on the received package, which is the defining characteristic of a NAT. Your postal analogy does show how you can get nice properties of address portability and location-hiding within a local network *without* resorting to address modification, i.e., it shows that you can have the flexibility you so prize without doing NAT. Maybe that's the lesson you should draw from this "naturally occurring" analog to packet networks. Steve
Re: [midcom] WG scope/deliverables
David, Ron Natalie and I renumbered hq.af.mil the week of the Loma Prieta quake. List the NAT implementations deployed at the time. The point you'll have made is that an-aide-to-renumbering NATs weren't. If they are marketed now as such, happy, but not necessary, is the marketeer. Eric
Re: NAT natural example, Re: [midcom] WG scope/deliverables
Ed, you seem to be ignoring the difference between identification, location, and routing. What the post office does is routing, not NAT. The NAT problem is a problem because IP addresses mix the concepts of identification and location in a single bit string. There's nothing natural about it, at least nothing more natural than shooting oneself in the foot. Brian Ed Gerck wrote: "Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Actually, in the UK you can do just what you wish ;-) You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the notion of using an IP number as a name -- but isn't this why we need DNS? ;-) And if you move from London to Belfast, this will still work? In the UK, as I said. I would think that other countries may have a similar system. Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. I don't want to be philosophical about this, but IMO this example actually supports the view that NATs are naturally occuring solutions to provide for local flexibility without decreasing global connectivity. The Internet NAT is perhaps less an "invention" than a translation of an age old mechanism that we see everywhere. We use the same principle for nicknames in a school for example. IMO, it is thus artificial to try to block Internet NATs. Far better would be to define their interoperation with other network components that we also need to use, in each case. Cheers, Ed Gerck
Re: NAT natural example, Re: [midcom] WG scope/deliverables
List: My example of the UK postal system, with addresses that behave as names, was NOT an attempt to make a parallel between the postal system and the full glory of the Internet. BTW, I don't believe in such parallels. Sorry to disapoint those that thought so! ;-) My sole puprose with that example was to show that there is a natural need for heterogeneous address systems and, therefore, for address translation. Many features found in Internet NAT are also IMO found in the UK postal scheme. The analogy is not perfect (as I said myself) but, what analogy ever is? So, rather than trying to find where the analogy is wrong, or claiming that I am ignoring the difference between identification, location, and routing, this dialogue was based on illustrating those two points, to wit: 1. there is a natural need for heterogeneous address systems and, 2. therefore, there is a natural need for address translation. Nothing else, and nothing more, was claimed. Cheers, Ed Gerck
Re: NAT natural example, Re: [midcom] WG scope/deliverables
At 8:12 AM -0800 2/16/01, Ed Gerck wrote: 1. there is a natural need for heterogeneous address systems and, Agreed. 2. therefore, there is a natural need for address translation. Only if there's some need to interconnect them, and even then only as a temporary measure, if at all, because there is an alternative and preferable way to deal with heterogeneous address systems -- and the only long-term successful way if history is any guide -- which is to layer a homogenous address system on top of them, which is the basic idea behind IP. Yes, the first attempt to join networks using different address systems is often to install translators, which is the way "interworking" was done before IP and Pup were invented, the way email systems were interconnected before universal adoption of the [EMAIL PROTECTED] name space, and the way people are gluing together the phone network and IP phones, not to mention the IPv4 and IPv6 Internets, today. Such approaches have always turned out to be so complex, fragile, unmanageable, unscalable, and function-limiting that they are sooner or later abandoned in favor of the one-global-namespace approach. If people understood that they didn't "need" to do translation, they just might take that step sooner and save everyone a lot of grief. Steve
Re: NAT natural example, Re: [midcom] WG scope/deliverables
1. there is a natural need for heterogeneous address systems and, okay 2. therefore, there is a natural need for address translation. no. it doesn't follow, at least not in the sense of address translation as done by NAT. there is a natural need for *routing* or *mapping* between higher and lower layer addresses, but this isn't the same thing as NAT. Keith
Re: [midcom] WG scope/deliverables
Bernard, Exactly. That is why 6to4 came out the way it did - it offers a way for a NATted IPv4 site to introduce non-NATted IPv6 without losing anything or throwing away anything. There are RFCs explaining the issues with NAT technically and objectively. I don't see why this generates comments about anti-NAT religion. It's obvious when you read those RFCs and think about P2P computing that NAT is a problem. If we don't avoid that problem in IPv6 we will have failed as engineers. Brian Bernard Aboba wrote: i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them.
RE: [midcom] WG scope/deliverables
Taking your valuable points a bit further, NAT avoidance arguments aren't likely to sell IPv6 to us large end users, because this is a problem for which it is difficult to construct a business case that will excite the non-technical managers who are in charge of blessing large capital expenses. By contrast, what will sell IPv6 will be "Killer Applications" that require IPv6. I am optimistic that advances like the UMTS Release 2000 Cell Phone standard, which requires IPv6, will provide the impetus for us end users to eventually justify the expenses of an IPv6 deployment. Should that business case be made, then 6to4 can ease this newer infrastructure into our systems. Once that occurs, then the advantages of a NAT-less IPv6 would become relevant to us large corporations. As it is, this is a theoretical concern at best to us due to the real-life implications (time, $$$) of deploying IPv6 into our networks compared to the advantages of cheaper stop-gap "solutions" like NATs. By saying this, I don't want to imply that I have any technical disagreement with the arguments that have led many to conclude that "NATs are evil." I am only stating that such arguments alone don't make a good business case. Similarly, while the best current approximations that the H-ratio, which determines when the IPv4 Address Space will be saturated for all practical purposes, will most likely occur in 2002 (i.e., NEXT YEAR) motivates me as a technical person, conveying these concerns into a viable business case that will motivate the "guys with the bucks" is a very different proposition indeed. That is why we need the "escape hatch" which midcom will hopefully provide us with, especially in view of the difficulties which current NAT approaches will introduce as we increasingly deploy peer-to-peer applications within our infrastructures. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] Sent: Friday, February 16, 2001 8:04 AM To: Bernard Aboba Cc: Randy Bush; Melinda Shore; Michael W. Condry; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables Bernard, Exactly. That is why 6to4 came out the way it did - it offers a way for a NATted IPv4 site to introduce non-NATted IPv6 without losing anything or throwing away anything. There are RFCs explaining the issues with NAT technically and objectively. I don't see why this generates comments about anti-NAT religion. It's obvious when you read those RFCs and think about P2P computing that NAT is a problem. If we don't avoid that problem in IPv6 we will have failed as engineers. Brian Bernard Aboba wrote: i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them.
Re: [midcom] WG scope/deliverables
| I don't see why this generates comments about anti-NAT religion. I prepared a shockingly rude but very funny riposte to this message, however the spirits intervened and decided to make a poorly-aimed wheel-mouse motion kill the editor in a surprising way. Unless this can be attributed to the universe's hatred of NAT in general, may I humbly suggest that this is a suggestion from the loa that we return to the discussion at hand, viz. how to make midboxes more useful to the people who choose to deploy them, by (for example) exposing servers inside to things outside, and so forth? Perhaps some kind soul will create a NAT-Haters mailing list or alt.flame.nat USENET newsfroup, since it seems like that would serve as a meeting-place for people who don't like NATs, as well as being a great place to rant about people's bruised knees, and may keep the running warfare from spilling onto unimaginable numbers of mailing lists? Sean. (who has never ever ranted on IPNGwg)
Re: NAT natural example, Re: [midcom] WG scope/deliverables
Steve Deering wrote: At 8:12 AM -0800 2/16/01, Ed Gerck wrote: 1. there is a natural need for heterogeneous address systems and, Agreed. 2. therefore, there is a natural need for address translation. Only if there's some need to interconnect them, and even then only as a temporary measure, if at all, because there is an alternative and preferable way to deal with heterogeneous address systems -- and the only long-term successful way if history is any guide -- which is to layer a homogenous address system on top of them, which is the basic idea behind IP. The other way, which can be theoretically justified as well, is to implictly define a "third system" that defines an internal reference for a set of relationships between the two address spaces. This third system can take the form of a NAT. Note that this third system is not an address space, much less a homogeneous one. And, as "The Tulip" discussion thread showed, such a NAT can take various forms that could be defined in an RFC with interoperation in mind. In particular, the capability of including the outside origin address:port as well as the global destination address:port in the translated packet which has the usual NAT-defined local destination address:port and the local origin address:port. Cheers, Ed Gerck
Re: [midcom] WG scope/deliverables
Unless this can be attributed to the universe's hatred of NAT in general, may I humbly suggest that this is a suggestion from the loa that we return to the discussion at hand, viz. how to make midboxes more useful to the people who choose to deploy them, by (for example) exposing servers inside to things outside, and so forth? I respectfully but firmly disagree that this is "the discussion at hand", or even that such a discussion is a useful. but if you must have that discussion, please take it to the midcom list. meanwhile other parts of IETF might actually be able work on solving the problems created by NATs rather than trying to perpetuate them. Perhaps some kind soul will create a NAT-Haters mailing list or alt.flame.nat USENET newsfroup, since it seems like that would serve as a meeting-place for people who don't like NATs, as well as being a great place to rant about people's bruised knees, and may keep the running warfare from spilling onto unimaginable numbers of mailing lists? there would be no point to a NAT-haters list. the entire purpose of refuting bogus claims about NAT is to promote better understanding of NATs among those who aren't aware of their problems, and such people wouldn't be on the list anyway. Keith
Re: [midcom] WG scope/deliverables
Taking your valuable points a bit further, NAT avoidance arguments aren't likely to sell IPv6 to us large end users, because this is a problem for which it is difficult to construct a business case that will excite the non-technical managers who are in charge of blessing large capital expenses. this is why some of us are working on solutions for interim deployment of IPv6 without the need for large capital expenses; i.e. at a similar cost to deployment of NAT. Keith
Re: [midcom] WG scope/deliverables
| I respectfully but firmly disagree that this is "the discussion at | hand", or even that such a discussion is a useful. but if you must | have that discussion, please take it to the midcom list. Ah, sorry, mea maxima culpa - I had misread (several times) the To:/Cc: line as containing the midcom address, when in fact it's just the Subject line. There is a small irony in making mistakes because of a mismatch between address components being used in places in a message other than the obvious source and destination address fields in a header, and the things actually used by the message transport system. | there would be no point to a NAT-haters lis Well if you are content to bruise your knees in public, be my guest. Sean.
Re: [midcom] WG scope/deliverables
On Wed, Feb 14, 2001 at 10:44:47PM -0500, Keith Moore wrote: it's hardly surprising that professional network administrators are more likely than the average home user to understand the limitations of NATs, [...] a significant percentage of the folks who will drive v6 deployment will be those who have learned about those problems the hard way and are in need of a real solution. they won't be fooled again. Keith, It has been my experience that many of the current network admins today believe NAT is the de facto way of connecting to the Internet. In fact, in one of the network classes I teach, it takes a lot of convincing on my part to show that NAT offers them very little security. Most net admins today have only seen a world through NAT eyes so they don't see the benefits of not having it. If you want people to live in a world without NAT, I think you have to have the killer application that simply will not function properly with it. This is much more difficult than it sounds. As hard as people like the IETF try, many new network protocols will continue to fail if 1) legacy applications are not supported or 2) killer applications are not available to drive the demand. John
Re: [midcom] WG scope/deliverables
David, IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. Odd. Every time I renumbered some site (hq.af.mil and sundry other sites sharing similar characteristics), there was neither a NAT prior to, nor subsequent to, the renumbering. I suggest that renumbering pre-existed, and did not motivate, NATtage of the NET. Eric
Re: [midcom] WG scope/deliverables
Well the message I got earlier was the IPv6 will not fix the NAT problem - true or not true? Well, it won't fix the NAT problem in scenarios where v6 is not deployed. But aside from the other answers you've received so far, I've also heard several people mention the need to support something they call "address policy domains." I don't understand why they need it and I don't understand why an address policy domain couldn't be described as, say, 209.4.89.208/28 and I don't understand why it would *require* NAT, but it is something I've heard on several occasions. Melinda
Re: [midcom] WG scope/deliverables
It's our collective job to ensure that IPv6 doesn't leave any of the motivations to do NAT intact. The "hiding" motivation (aka address policy domains) is bogus anyway, and has never been a valid reason for doing IPv4 NAT, so it's particularly hard to combat. Brian Melinda Shore wrote: Well the message I got earlier was the IPv6 will not fix the NAT problem - true or not true? Well, it won't fix the NAT problem in scenarios where v6 is not deployed. But aside from the other answers you've received so far, I've also heard several people mention the need to support something they call "address policy domains." I don't understand why they need it and I don't understand why an address policy domain couldn't be described as, say, 209.4.89.208/28 and I don't understand why it would *require* NAT, but it is something I've heard on several occasions. Melinda
Re: [midcom] WG scope/deliverables
It's our collective job to ensure that IPv6 doesn't leave any of the motivations to do NAT intact. i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. randy
Re: [midcom] WG scope/deliverables
Eliot, On Wed, 2001.02.14, Eliot Lear wrote: With all the discussion of Napster and so-called "peer to peer" networking, I think NATs are going to become far more visible to users as these applications grow in popularity. Today, you can use something like Gnutella if at least one party is not behind a NAT. With the addressless overlay architecture, you don't need any party to be outside the firewalls. So the premise is incorrect. I'm keeping relatively quiet because I'm busy implementing a prototype system myself, and hope to demo it within this semester (honto ni) :-) (Please read my soon-to-be-published revised paper, which Carpenter says is much clearer than my I-D, temporarily housed at http://affine.watson.ibm.com/tmp/ - see Annals - unlike the Triad, this one's been peer-reviewed and published twice, plus almost all IP protocols would work, not just TCP.) regards, prasad.
Re: [midcom] WG scope/deliverables
Keith, It has been my experience that many of the current network admins today believe NAT is the de facto way of connecting to the Internet. In fact, in one of the network classes I teach, it takes a lot of convincing on my part to show that NAT offers them very little security. Most net admins today have only seen a world through NAT eyes so they don't see the benefits of not having it. As I've seen a lot of this kind of thinking even in IETF, I have no trouble at all believing it exists elsewhere. But people can learn over time, even without a killer app.Of course the problem with NAT is that it inhibits the spread of killer apps - people will never see useful new applications that could run without NATs because NATs prevent them from having a chance to try them out. For me, the entire motiviation behind 6to4 was to give people a way to deploy new kinds of apps without first having to upgrade the infrastructure - the biggest hurdle being to get rid of NATs. If you want people to live in a world without NAT, I think you have to have the killer application that simply will not function properly with it. This is much more difficult than it sounds. As hard as people like the IETF try, many new network protocols will continue to fail if 1) legacy applications are not supported or 2) killer applications are not available to drive the demand. My goals are more modest than that. I accept that NAT will be a fixture in IPv4 forever, and that IPv4 will be used to support important legacy apps for a long time, maybe 20 more years. But I'm trying to get folks in IETF to recognize the problems with NATs (you have to start somewhere), I'm trying to get us to strongly discourage NATs in IPv6, and I'm trying to get us to develop technically sound alternatives to the problems that NATs purport to solve. Keith
Re: [midcom] WG scope/deliverables
On Thu, 2001.02.15, Lloyd Wood wrote: that webpage is still black on black. The style file on http://affine.watson.ibm.com/tmp/ has been commented out, since some versions of Mozilla (4.05 on SunOS 5.6??) appear to be broken. -p.
Re: [midcom] WG scope/deliverables
It's our collective job to ensure that IPv6 doesn't leave any of the motivations to do NAT intact. i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. to the extent that anti-NAT is a religion it is because NAT is a religion - in the sense that it is accepted without question as good and necessary. for folks who have already accepted NATs as gospel, the only kind of argument that will get their attention is a religious one. you have to start somewhere. folks who understand how NATs directly obstruct some of those 'useful and concrete major direct goals', can stop thinking of "anti-nat" as a religion and start thinking of a NAT-free network as a sub-goal. even so, those 'major and concrete direct goals' will differ from one person to another. my goal is to have an internet that is versatile enough to support a wide variety of applications - peer-to-peer and multi-peer applications in particular. others want to make money by producing a particular kind of product. many folks who have different 'major and concrete direct goals' might still have 'anti-nat' as a common sub-goal. blind acceptance of anti-NAT is no more desirable than blind acceptance of NAT. especially in this community, people need to *understand* the implications of each choice. Keith
Re: [midcom] WG scope/deliverables
i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. to the extent that anti-NAT is a religion it is because NAT is a religion no, it's a market reality. we may not like it, but we'd be fools to deny it. randy
Re: [midcom] WG scope/deliverables
i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. to the extent that anti-NAT is a religion it is because NAT is a religion no, it's a market reality. we may not like it, but we'd be fools to deny it. I agree that one would be a fool to deny that NATs exist and are widely deployed. Indeed, there would be no need for an anti-NAT effort if this were not the case - so the anti-NAT folks inherently accept this. But NATs are a religion even beyond the reality of present-day deployment. Indeed, it's the tendency of people to make the leap from "market reality" to "this is the way things should be" or "things cannot possibly be any different" that causes me the greatest concern. Such views, I submit, are a form of religion. Keith
Re: [midcom] WG scope/deliverables
Such views, I submit, are a form of religion. Religion is a belief in a power higher than oneself. NAT-mania is a form of mass delusion. Cheers, RGF Robert G. Ferrell, CISSP Who goeth without humor goeth unarmed.
RE: [midcom] WG scope/deliverables
i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them.
RE: [midcom] WG scope/deliverables
i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them. and, if we can make v6 very attractive (left as exercise to student) then its success may relieve some perceived need for nats. but there are far more useful goals to achieve by making it attractive and deployed. and we should focus on them, not the anti-nat obsession. [ unless, of course, we think that there is enough left of our foot to keep shooting at it. ] randy
Re: [midcom] WG scope/deliverables
You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the I suspect it only works in rural areas - I recall walking past 27A Wimpole Street and humming the rain in spain. Back where I grew up, the village postmen not only deliver without numbers, but read the letters too for those who can't :) notion of using an IP number as a name -- but isn't this why we need DNS? ;-) Beg to differ - the reason we need the DNS is because its hierarchy mirrors instead of routing. If it (the hierarchy) did routing, it (the DNS) wouldn't be mirroring and that might change the loading/scalability issues with the DNS. -prasad
Re: [midcom] WG scope/deliverables
In message [EMAIL PROTECTED], Ed Gerck writes: Actually, in the UK you can do just what you wish ;-) You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the notion of using an IP number as a name -- but isn't this why we need DNS? ;-) And if you move from London to Belfast, this will still work? Relevance left as an exercise for the student. --Steve Bellovin, http://www.research.att.com/~smb
Re: [midcom] WG scope/deliverables
Keith, At 10:44 PM 2/14/2001 -0500, Keith Moore wrote: If end users are required to modify configuration files, you will see NAT so they don't have to. not if the NATs cause more pain than modifying the config files. True. However, a company that produces a NAT that is more painful to use/operate than modifying config files will not likely be in business long. I presume that "technogeeks" includes networking professionals who can't make their B2B applications work reliably over NATs? Given the penetration of NAT, particularly in the business world, I suspect B2B applications that do not work with NAT will not exist too long. Rgds, -drc
Re: [midcom] WG scope/deliverables
Keith, At 10:44 PM 2/14/2001 -0500, Keith Moore wrote: If end users are required to modify configuration files, you will see NAT so they don't have to. not if the NATs cause more pain than modifying the config files. True. However, a company that produces a NAT that is more painful to use/operate than modifying config files will not likely be in business long. In many cases, NATs are already more painful than modifying config files... it's just that the pain associated with using NATs comes later. I presume that "technogeeks" includes networking professionals who can't make their B2B applications work reliably over NATs? Given the penetration of NAT, particularly in the business world, I suspect B2B applications that do not work with NAT will not exist too long. hence the desire to tunnel everything over HTTP, which produces its own pain. Keith
Re: [midcom] WG scope/deliverables
Given the penetration of NAT, particularly in the business world, I suspect B2B applications that do not work with NAT will not exist too long. from the little i have seen, because b2b usually wants authentication, authorization, and encryption, a lot of that stuff goes through gateways/ proxies/firewalls that seem to ship with nat turned on by default. often this is not needed sigh. randy
NAT natural example, Re: [midcom] WG scope/deliverables
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Actually, in the UK you can do just what you wish ;-) You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the notion of using an IP number as a name -- but isn't this why we need DNS? ;-) And if you move from London to Belfast, this will still work? In the UK, as I said. I would think that other countries may have a similar system. Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. I don't want to be philosophical about this, but IMO this example actually supports the view that NATs are naturally occuring solutions to provide for local flexibility without decreasing global connectivity. The Internet NAT is perhaps less an "invention" than a translation of an age old mechanism that we see everywhere. We use the same principle for nicknames in a school for example. IMO, it is thus artificial to try to block Internet NATs. Far better would be to define their interoperation with other network components that we also need to use, in each case. Cheers, Ed Gerck
Re: [midcom] WG scope/deliverables
anyway, what's the half-life of a piece of network equipment? 2-3 years? In the consumer space, it's probably the life of the customer's arrangement with the service provider. While turnover is high with dialup ISPs, it is presumably lower with xDSL and Cable modems. So I would be looking at more like 4-5 year lifetimes (roughly equal to a PC) without upgrading the NAT code load (which means that even if IPv6 native support were available, most customers would not do the upgrade). existing NATs are going to be discarded, or at least upgraded, within a short time anyway. I wish that were true -- but in the consumer space, people just aren't very interested in futzing with network equipment unless their provider tells them to. So it is more realistic to assume that equipment stays in place for a substantial period. NATs are more entrenched in people's minds than they are in reality. Today, NAT penetration among consumers isn't very high because networked multi-PC homes are relatively rare. However, as multiple device homes proliferate along with home networking, I would expect the majority of consumer PCs to be behind NATs by 2005. Unless we start thinking now about the minimal NAT functionality necessary to deploy IPv6, and get this into shipping NATs soon, we will face very substantial barriers to IPv6 adoption down the road. It's being worked on. Watch the I-D directory. I'm watching ;)
Re: NAT natural example, Re: [midcom] WG scope/deliverables
At 3:41 PM -0800 2/15/01, Ed Gerck wrote: "Steven M. Bellovin" wrote: You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. ...Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. They also do it without removing the original destination address and replacing it with another one -- the original envelope arrives at the house with the destination address still saying "The Tulip", i.e., it has not been translated, and thus is not analogous to NAT. If delivery is accomplished by having all the necessary the UK post offices and postpersons remember a routing from "The Tulip" to its current street address, then its IP analog is having the routers within a site maintain a host route for a specific IP address. If, on the other hand, only the UK-entry post office maintains the mapping and sticks the original envelope inside another envelope (or puts a yellow sticky note over the original address), addressed to The Tulip's current street address, then its IP analog is having the border router maintain a tunnel to an individual interior host, encapsulating the original packet with another header. A closer postal analog to the typical port-and-address-mapping NAT is a system in which postal envelopes only have room for a street address or a town name, but not both. If I send a letter to someone outside my town, the letter starts off with a return address of: Steve Deering 123 Main Street and the town's post office overwrites that return address, changing it to: Priscilla Presley San Jose, CA, USA and they remember for a while that they did that, so that if my correspondent decides to reply to that return address, the town post office knows who it should be delivered to. (They replaced my name because someone else named Steve Deering recently sent mail from another street address in my town, and the only way to keep the replies separate is to change the name that I will be [temporarily] known by in the outside world.) At some point, they discard the remembered mapping, to free up some names. Perhaps they do that based on a time-out, in which case the mapping may disappear before we are finished corresponding, and thus cause our communication to fail. Or maybe they open up our letters and look at the contents to try to identify the final letter of our correspondence, to guess when we might be done. Of course that latter approach doesn't help if they don't understand what language our letters are written in, so maybe they decide to limit us to only a small choice of languages, and just discard anything they don't understand. Furthermore, no one outside my town can initiate a correspondence with me, unless I work out some arrangement with the post office to get long term external use of someone's (preferably my own) name. Or else I have to go and get a town name for myself. I don't want to be philosophical about this, but IMO this example actually supports the view that NATs are naturally occuring solutions to provide for local flexibility without decreasing global connectivity. Since the example was not an example of a NAT, I don't think it supports any such view. However, I suppose a postal system like the one I described might "naturally occur" as a response to having envelopes that were no longer big enough to contain full addresses. But I think it much more likely that post offices and people would somehow arrange to just use bigger envelopes, rather than incurring all the extra complexity, cost, fragility, and loss of functionality of the translating approach, except as a temporary stop-gap. Unless, that is, we were talked out of it by folks claiming that changing the size of envelopes would be an impossibly large task, and that we're better off anyway with the translating system, because our personal names and street addresses can be kept secret within our town, and we can change the name of our town any time we like without bothering anybody in it. Steve
Re: NAT natural example, Re: [midcom] WG scope/deliverables
In message [EMAIL PROTECTED], Ed Gerck writes: "Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Actually, in the UK you can do just what you wish ;-) You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the notion of using an IP number as a name -- but isn't this why we need DNS? ;-) And if you move from London to Belfast, this will still work? In the UK, as I said. I would think that other countries may have a similar system. Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. Last I checked, Belfast was in the UK, though I realize that some folks wish it were not so. But you missed my point -- as you note above, the house name is known to "that post office". In other words, there is hierarchy in the routing algorithm; it's not globablly known, or even known throughout the UK. The same is true of the Internet, and it's why IP addresses aren't portable. I don't want to be philosophical about this, but IMO this example actually supports the view that NATs are naturally occuring solutions to provide for local flexibility without decreasing global connectivity. The Internet NAT is perhaps less an "invention" than a translation of an age old mechanism that we see everywhere. We use the same principle for nicknames in a school for example. IMO, it is thus artificial to try to block Internet NATs. Far better would be to define their interoperation with other network components that we also need to use, in each case. Block them? Not at all; I have no desire to do that. But we need to recognize that *with the current Internet architecture*, there are some inherent limitations. To use your analogy, suppose that senders sometimes wrote their house name on the letter enclosed in the envelope -- but they didn't include the post office name, so the recipient couldn't reply. Or imagine that the Post Office only kept track of house names when there was a recent outgoing letter. That's the reality of NAT today. Please pay careful attention to two things I did *not* say. I did *not* say that NATs were an irrational engineering choice in today's environment. In fact, they clearly are rational in some circumstances, despite their disadvantages. Second, I didn't say that one couldn't have designed an Internet architecture with nested addresses. Quite obviously, that could have been done. But it wasn't, and we have an Internet that likes single, fixed-length addresses. NATs are at best an ugly add-on in such a world. (My personal techo-religion preaches that *all* successful systems run out of address space, and that you're better off planning for it up front. I (among others) argued strongly for IPv6 addresses of 8, 16, 24, or 32 bytes, precisely to plan ahead. In fact, the penultimate design called for fixed-length, 8-byte addresses. The switch to 16 bytes was done to satisfy those of us who feared that that was not nearly enough.) --Steve Bellovin, http://www.research.att.com/~smb
Re: NAT natural example, Re: [midcom] WG scope/deliverables
Steve Deering wrote:
At 3:41 PM -0800 2/15/01, Ed Gerck wrote:
You give a name to your house (say, "The Tulip") and
the post office knows where The Tulip is. If you move,
you can do the same at your new location, provided
there is no conflict.
...Note that this is a natural example of NAT,
in which the post office is doing the address translation to a local
address that only that post office knows, but which is globally
reachable through that post office. And the post office does so
without changing the global addresses or the local addresses.
They also do it without removing the original destination address and
replacing it with another one -- the original envelope arrives at the
house with the destination address still saying "The Tulip", i.e., it
has not been translated, and thus is not analogous to NAT.
I think you got the example addresses reversed. In the case I mention,
"The Tulip" is the global address and (for the sake of example) suppose
now that "545 Abbey St." is the local physical address known to the post office.
Thus, when the mailman delivers an envelope addressed to "The Tulip" at
"545 Abbey St.", that mailman is doing address translation -- and he may
even have written "545 Abbey St." on the envelope as a reminder. So,
when the original envelope arrives at the destination address it did so not
because it had "The Tulip" written on it but because the post office was
able to do address translation to the *current* location which is "545 Abbey St."
If another location is assigned to "The Tulip" (for example, because the owner
Mr. Tulip moved), the post office will deliver the original envelope there and
not at "545 Abbey St."
Note that the local address which only the post office (and Mr. Tulip) knows is
"545 Abbey St." while the global address is "The Tulip".
In Internet NAT terms, "The Tulip" is the globally routable IP number for my DSL,
the post office is my NAT box and the physical address "545 Abbey St." is the
local, non-routable IP number of my host A. For my other hosts, I simply tell
the NAT box (post office) what is the local IP number that will receive the next
packet for "The Tulip" -- my single global name. If now you add a mailbox number to
"The Tulip" you have the same functionality of port translation as well, where
different local addresses (for private mail, for example) will correspond to different
"n" in "The Tulip, PO Box n".
In other words, this is a natural NAT example and clearly supports the view that
NATs are naturally occuring solutions to provide for local flexibility (Mr. Tulip
can change residence at will and can have more than one recipient for private mail)
without decreasing global connectivity ("The Tulip" is always responsive).
Cheers,
Ed Gerck
Re: NAT natural example, Re: [midcom] WG scope/deliverables
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: "Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Actually, in the UK you can do just what you wish ;-) You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. This seems to be more similar to the notion of using an IP number as a name -- but isn't this why we need DNS? ;-) And if you move from London to Belfast, this will still work? In the UK, as I said. I would think that other countries may have a similar system. Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. Last I checked, Belfast was in the UK, though I realize that some folks wish it were not so. It will work in the UK was my reply. But you missed my point -- as you note above, the house name is known to "that post office". In other words, there is hierarchy in the routing algorithm; it's not globablly known, or even known throughout the UK. I disagreed with your point, not missed it. "The Tulip" together with *that* post office's postcode (for example CM22 6SX, which they assign on a geographical basis) is globally routable. Even from Belfast ;-) The same is true of the Internet, and it's why IP addresses aren't portable. IP addresses are not portable simply due to a design choice. If IP numbers were designed the way the UK designed their postal service long ago, then IP numbers would be portable indeed. IMO, it is thus artificial to try to block Internet NATs. Far better would be to define their interoperation with other network components that we also need to use, in each case. Block them? Not at all; I have no desire to do that. But we need to recognize that *with the current Internet architecture*, there are some inherent limitations. To use your analogy, suppose that senders sometimes wrote their house name on the letter enclosed in the envelope -- but they didn't include the post office name, so the recipient couldn't reply. I see that we are in agreement with my post office example. "The Tulip" together with the postal code (ie, the post office's "name") is globally routable. Or imagine that the Post Office only kept track of house names when there was a recent outgoing letter. These are security choices -- the time to live in a NAT could be unlimited, with fixed port numbers. The address:port numbers could also be pre-registered, before any message is sent. This is the current UK post-office model. Likewise, the UK post-office model could only kept track of house names when there was a recent outgoing letter, with "recent" defined by policy. That's the reality of NAT today. IMO, this is simply a security choice -- NATs could work with the current UK post-office model as well. But if the house owner only wants to allow the post office to kept track of his house's name when there was a recent outgoing letter, then who is going to say otherwise? After all, he may refuse to receive any letter and just send them One way or another, the house (network) owner is sovereign over his house (network). My network is my castle. Please pay careful attention to two things I did *not* say. I did *not* say that NATs were an irrational engineering choice in today's environment. In fact, they clearly are rational in some circumstances, despite their disadvantages. I would say characteristics, not disadvantages. An apple is a bad orange. Second, I didn't say that one couldn't have designed an Internet architecture with nested addresses. Quite obviously, that could have been done. In my view, this is already done. It works this way, although not engineered this way. The Internet has its own dynamics is the lesson I see in this. It routes around blocks ;-) But it wasn't, and we have an Internet that likes single, fixed-length addresses. NATs are at best an ugly add-on in such a world. An alternative view is that we have an Internet that likes so much to work with heterogeneous networks that it now supports NATs even though NATs were not originally designed into it. (My personal techo-religion preaches that *all* successful systems run out of address space ;-) agreed, but only systems with finitary address space. , and that you're better off planning for it up front. I (among others) argued strongly for IPv6 addresses of 8, 16, 24, or 32 bytes, precisely to plan ahead. In fact, the penultimate design called for fixed-length, 8-byte addresses. The switch to 16 bytes was done to satisfy those of us who feared that that was not nearly enough.) Going further with
Re: NAT natural example, Re: [midcom] WG scope/deliverables
Steve Deering wrote:
At 6:21 PM -0800 2/15/01, Ed Gerck wrote:
...
In Internet NAT terms, "The Tulip" is the globally routable IP number for
my DSL, the post office is my NAT box and the physical address
"545 Abbey St." is the local, non-routable IP number of my host A.
That would be analogous to having "The Tulip, UK" be the address of
a post office, with all houses served by that post office sharing
the same global address of "The Tulip, UK". That indeed is like a
NAT, but is not the same as the original example.
To be precise and still with the original example, the analogy is that
"The Tulip, CMZ 62N, UK " is the full global address (which was described
in the context of my email as "The Tulip" at that post office).
The full designation "The Tulip, CMZ 62N, UK" is thus similar to a globally
routable address (Internet IP) that is available at the post office
"CMZ 62N, UK" (NAT box) and which may at times correspond
to a house at "545 Abbey St" (host A) or to a house at "636 North Av"
(host B), which mapping that post office knows at each time and uses
to direct correspondence to the proper house without revealing to the
outside world what that local address might be -- ie, either "545 Abbey St."
(host A) or "636 North Av" (host B), or any other.
All houses served by that post office share "CMZ 62N, UK" while the house
name is similar to a port number in NAT (different for each house being served).
Note also that my NAT analogy only dealt with receiving mail, not sending mail.
Mr. Tulip may send mail any way he wishes, with a global return address as
"The Tulip, UK", with a local address as "545 Abbey St", with a fake return
address or even with no return address.
Let me now address your objection that "A host behind a NAT, on the other hand,
doesn't know its own global address and, in most cases, doesn't even have a
global address (or one port's share of a global address), except temporarily as a
side-effect of sending a packet to the outside world". We may agree that
we are dealing here with two different processes -- sending information and
receiving information. An UK post office was presented as a NAT analogy
for receiving information, not to send information. In receiving information,
Mr. X (a host behind the NAT) does not need to know how the house
he just moved in is named at the post office -- and, nonetheless, he will get
any letters addressed to "The Tulip, CMZ 62N, UK" if that is the house's name at
the post office "CMZ 62N, UK". The temporary property of the global address is
also present in the UK post office example for receiving information -- just that
the time scale may be hundreds of years, not milliseconds.
Your other objection was that "In the case of NAT, on the other hand,
the destination address used across the public part of the Internet is no longer
present in the packet finally delivered to the destination host -- it has been
been replaced by (i.e., translated to) a different address". My reply is
that this does not occur in NATs if the destination address is also included
in the packet payload, which is the case here -- the envelope is part of
the message's payload in the post office case. Pls see also my last comment,
below.
In other words, this is a natural NAT example...
The original example, of a single house with the global address of
"The Tulip, UK" is a naturally occurring example of something like ARP
or something like tunneling, not something like NAT.
I agree that you can define many different analogies, from that example. But,
as above, if you consider the way that information is received then a NAT box
is IMO one valid analogy for reception because it satisfies the functionality
observed in a NAT box when receiving packets. Yes, the UK post office does
not erase the global address on the envelope but a NAT will also keep that
information in the translated packet if it is in the packet's payload (which
is the case for the letter's envelope), and without any impact in its functionality
as a NAT.
The distinction is betweeen doing a mapping/encapsulation and doing an
address substitution. NATs are all about doing address substitution; the
post office does mapping/encapsulation to deliver to The Tulip.
At the post office routing level, letters that enter a common input bin are moved to
different output bins at the post office. The common input bin is a globally
routable address such as "The Tulip, CMZ 62N, UK", "The Raven, CMZ 62N, UK",
etc. -- where the only part that is globally meaningful is "CMZ 62N, UK". Each
output bin corresponds to a local address mapped from the local qualifier
"The Tulip", "The Raven", etc. Each output bin, however, has no marking for
any local qualifier ("The Tulip"), just for a local address ("545 Abbey St").
Thus, there is no encapsulation at the post office routing level -- anyone
looking just at the bin "545 Abbey St" could not tell which local qualifier
was used for the letters inside the
Re: [midcom] WG scope/deliverables
Eric, Odd. Every time I renumbered some site (hq.af.mil and sundry other sites sharing similar characteristics), there was neither a NAT prior to, nor subsequent to, the renumbering. If they are already using NAT, it is most likely they wouldn't need your services to renumber, no? Rgds, -drc
Re: [midcom] WG scope/deliverables
Noel, At 01:20 AM 2/15/2001 -0500, J. Noel Chiappa wrote: Why do I have to change street addresses just because I moved? A very good reason your name is separate from your address. Good thing you didn't choose telephone numbers in your rant, huh? In any event, my point (in case you missed it before getting wound up for your rant) was that people find renumbering hard will choose not to renumber given the choice. NAT provides them a choice, like it or not (I personally don't care -- I see NAT as a tool with advantages and disadvantages like any other tool). As long as IPv6 has only one namespace to say *who* you are, as well as *where* you are, your address will change when you change providers. Yes. It astonishes me how many people have been unable to grasp this and assume that magic happens when you go from 32 bits to 128 bits. As the old hackers say, "That's not a bug, that's a feature." The bug is that who and where are not separated, but I suspect you won't argue with that. Rgds, -drc
Re: [midcom] WG scope/deliverables
Well the message I got earlier was the IPv6 will not fix the NAT problem - true or not true? I assume with IPv6 there is no need for NATs. Who thinks they will still be around - humm maybe if the ISP charge a fortune for 4 IP addresses vs 1 IP address (IPv6 or IPv4). At 11:53 AM 2/2/2001 -0800, Greg Minshall wrote: Keith, perhaps. but I note that for many of the examples you quoted, "dealing with them" was not nearly as nice as "not having to deal with them". absolutely. i was very happy when we moved from the previous world to the (more or less pure) IP world. i will be very happy when we move from the NAT world to the (more or less pure) IPv6 world. Greg (who wrote email gateways in a past life) Michael W. Condry Director, Network Edge Technology
Re: [midcom] WG scope/deliverables
Well the message I got earlier was the IPv6 will not fix the NAT problem - true or not true? depends on how you define "the NAT problem" - if you define it as a shortage of addresses, then IPv6 *does* solve the NAT problem - provided, of course, that the RIRs are willing to assign reasonable sized blocks (much larger than IPv4 assignments) and similarly, that ISPs do not charge onerous amounts to route reasonably sized address blocks to customers. - if you define it as the ability to "plug and ping" small networks into the Internet, then (as far as I can tell) we still need a small piece of protocol beyond IPv6 to have a "pure IPv6" plug-and-ping solution. in the interim, either PPP or DHCP will give you an IPv4 address; this combined with 6to4 gives you a /64 on a plug-and-ping basis, and the protocol work for this is already done. - if you define the NAT problem as the ability to easily renumber networks (or more precisely, the ability to avoid needing to renumber networks), then IPv6 probably still needs a bit of work until renumbering an IPv6 network is as painless an operation as "renumbering" an IPv4 network using a NAT. of course the NAT produces its own kind of pain, which you might or might not realize is part of the cost of using a NAT to renumber. - if you define the NAT problem as the ability to provide the security and illusion of security that folks get from NATs, rest assured that the same degree of security and illusion can be provided using IPv6 mechanisms. However, with IPv6, the NATs won't prevent applications that need stable addresses from having them. - if you define the NAT problem as the inability to run certain kinds of applications, then yes, IPv6 does solve those problems. however you have to modify your application to run IPv6. - if you define the NAT problem as the difficulty associated with trying to bilaterally connect together various IPv4 networks, each of which uses potentially overlapping address spaces, then yes IPv6 solves this problem. (IPv6 seems like a big win for B2B communications) so to answer your question succinctly I'd say "mostly true". I assume with IPv6 there is no need for NATs. Who thinks they will still be around - humm maybe if the ISP charge a fortune for 4 IP addresses vs 1 IP address (IPv6 or IPv4). it's probably misleading to think of IPv6 vs. NATs as an either-or situation. NATs will definitely be around for awhile - to provide connectivity for legacy v4-based applications and networks, (email and web will be primarily v4-based for a long time) and NAT-PT to provide some measure of interoperability between v6 and v4 apps. However, one hopes that NATs will not interfere with pure v6 connectivity, so that applications that are written for IPv6 will be able to rely on the increased functionality. Keith
Re: [midcom] WG scope/deliverables
to correct something I just miswrote: - if you define it as the ability to "plug and ping" small networks into the Internet, then (as far as I can tell) we still need a small piece of protocol beyond IPv6 to have a "pure IPv6" plug-and-ping solution. in the interim, either PPP or DHCP will give you an IPv4 address; this combined with 6to4 gives you a /64 on a plug-and-ping basis, and the protocol work for this is already done. it should read "...this, combined with 6to4 gives you a /48 on a plug-and-ping basis..." Keith
Re: [midcom] WG scope/deliverables
At 05:53 PM 2/14/2001 -0800, Michael W. Condry wrote: I assume with IPv6 there is no need for NATs. IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. Rgds, -drc
Re: [midcom] WG scope/deliverables
IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. I don't think so - first, because IPv6 has more hooks for renumbering than v4 (though more work is needed); and second, because a lot of folks will want to use IPv6 precisely because they need to avoid NAT breakage. I'm not saying that there won't be any v6 NATs in the world (though we should solidly and firmly declare them to be a protocol violation), but they should be few and far between. Keith
Re: [midcom] WG scope/deliverables
Keith, At 10:02 PM 2/14/2001 -0500, Keith Moore wrote: IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. I don't think so - first, because IPv6 has more hooks for renumbering than v4 (though more work is needed); If end users are required to modify configuration files, you will see NAT so they don't have to. and second, because a lot of folks will want to use IPv6 precisely because they need to avoid NAT breakage. Technogeeks, perhaps. The vast majority of people on the Internet who are behind NATs most likely don't even know it. Rgds, -drc
Re: [midcom] WG scope/deliverables
IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. I don't think so - first, because IPv6 has more hooks for renumbering than v4 (though more work is needed); If end users are required to modify configuration files, you will see NAT so they don't have to. not if the NATs cause more pain than modifying the config files. and second, because a lot of folks will want to use IPv6 precisely because they need to avoid NAT breakage. Technogeeks, perhaps. The vast majority of people on the Internet who are behind NATs most likely don't even know it. I presume that "technogeeks" includes networking professionals who can't make their B2B applications work reliably over NATs? there are two major classes of NAT users: (1) home users of "internet connection sharing" and (2) businesses using NATs to connect private networks to the Internet and to one another. both groups are generally aware that the NATs exist, though the home users might not use the term NAT to describe them and might not be as well versed in how they function. it's hardly surprising that professional network administrators are more likely than the average home user to understand the limitations of NATs, and the home user is often less demanding - the casual home user who just wants to be able to browse the web at the same time as the kids might never notice the difference. but overall, both kinds of users are learning that the presence of a NAT causes some things to break, just as people once had to learn that rewriting of email addresses across gateways caused things to break. a significant percentage of the folks who will drive v6 deployment will be those who have learned about those problems the hard way and are in need of a real solution. they won't be fooled again. Keith
Re: [midcom] WG scope/deliverables
Dave, Technogeeks, perhaps. The vast majority of people on the Internet who are behind NATs most likely don't even know it. With all the discussion of Napster and so-called "peer to peer" networking, I think NATs are going to become far more visible to users as these applications grow in popularity. Today, you can use something like Gnutella if at least one party is not behind a NAT.
Re: [midcom] WG scope/deliverables
From: "David R. Conrad" [EMAIL PROTECTED] IPv6 does not solve the need to renumber if you change providers ... Until that issue is addressed, there will be NATs. Even for v6. Oh, I can't resist: It's completely appalling that when I move to a new house, my street address changes. It's such a hassle; I have to tell all my friends to update their address books, get new business cards, etc, etc, etc. Why do I have to change street addresses just because I moved? Can't ICANN^H^H^H^H^H the US Post Office fix this? No? Well, clearly they are in the pay of some evil nasty multi-nationals (or they *are* an evil, nasty multi-national). I demand a Congressional hearing at once! It's all a US Government plot to shaft the rest of the world! The UN needs to look into this! /Rant As long as IPv6 has only one namespace to say *who* you are, as well as *where* you are, your address will change when you change providers. As the old hackers say, "That's not a bug, that's a feature." Noel
Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables
In message [EMAIL PROTECTED], Scott Brim type d: Although address obfuscation through combining NAT with your firewall can provide a small amount of additional security. against which attacks ? it doesnt provide better privacy, or non repudation, or access control, or any normal service that one would regard as an enhancement of security - in fact, having one address shared by multiple host s means there are less things an attacker needs to remember :-) cheers jon
Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables
Jon, this is a nit, two digressions off the main thread, so I'll take it off-list. More mail soon. ...Scott On 4 Feb 2001 at 17:29 +, Jon Crowcroft apparently wrote: In message [EMAIL PROTECTED], Scott Brim type d: Although address obfuscation through combining NAT with your firewall can provide a small amount of additional security. against which attacks ? it doesnt provide better privacy, or non repudation, or access control, or any normal service that one would regard as an enhancement of security - in fact, having one address shared by multiple host s means there are less things an attacker needs to remember :-) cheers jon
Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables
On Sat, Feb 03, 2001 at 10:50:08AM -0800, Grenville Armitage wrote: Einar Stefferud wrote: [..] had my own home system and discovered that I had no interest in being totally visible and accessible at all times, especially when I was not always around to monitor things. So, now I am very happy behind my little XRouter NAT box, with an ISP service out there where I can have a login shell if I wish. NAT doesn't primarily provide security, a firewall does. A firewall doesn't have to do NAT. If you dont mind the number of IP addresses you get from your ISP, install a smart firewall and ditch the NAT box (or twiddle some config options in your Xrouter... whatever) Although address obfuscation through combining NAT with your firewall can provide a small amount of additional security. ...Scott
harbinger, Re: [midcom] WG scope/deliverables
Greg Minshall wrote: absolutely. i was very happy when we moved from the previous world to the (more or less pure) IP world. i will be very happy when we move from the NAT world to the (more or less pure) IPv6 world. Greg (who wrote email gateways in a past life) I think that it is a truism that homogeneous networks are simpler. However, if this becomes "the" reason not to use heteregenous networks (and NATs), then we are denying the usefulness of local solutions to local problems. We are also restraing locally controlled growth and optimizations. Since it is also a truism that a local maximum (or, minimum) does not have to be a global maximum (or, minimum), then we see that a homogeneous network must not be the best global solution either. In other words, that is why the Net never was and resists being be a homogeneous network. It would be a less efficient design. Thus, we need to be able to cope with diversity, not try to iron it out. The NAT ugly duckling, the misfit to some, may well be a harbinger. Cheers, Ed Gerck
Re: harbinger, Re: [midcom] WG scope/deliverables
Keith Moore wrote: Ed, We agree that the net has never been entirely homogeneous, and that it would be a Bad Thing if people were forced to make their local nets conform to someone's idea of the Right Way to do their networks. Yes. Thus, I have few problems with folks who want to use NATs within their local networks and who understand and accept the limitations of that approach - even though, as you are fond of pointing out, this is an example of a local optimization that is sub-optimal for the global Internet community. If it would be imposed. But IMO it is, however, globally optimal for the Internet community to be able to solve their problems locally. OTOH, I have a big problem with constraining and/or encouraging folks to use NATs, while misleading folks about their limitations; misleading is always bad. and with attempts to make NATs a part of the Internet architecutre and thereby forcing everyone to accept those limitations. This is where we seem to diverge. IMO: (1) NATs are part of the Net archictecture and a harbinger, not an intrusion or a misfit; (2) everything has limitations, but having no choice is always the worse limitation. So, rather than following the "let a thousand standards bloom" dictum, I think that NATs (and similar approaches) are actually a way to provide for interoperation and reduce heterogeneity -- and its effect, which is isolation. Cheers, Ed Gerck
Re: harbinger, Re: [midcom] WG scope/deliverables
Ed Gerck wrote: [..] Thus, we need to be able to cope with diversity, not try to iron it out. Depends why the diversity exists. Coping is the reaction of people who feel they cannot change the underlying causes. Apparently not everyone feels so powerless that NAT is their only answer. What you call "ironing out", others call "minimising the reasons for gratutitous diversity" cheers, gja Grenville Armitagehttp://members.home.net/garmitage/ Bell Labs Research Silicon Valley
Re: harbinger, Re: [midcom] WG scope/deliverables
Ed, We agree that the net has never been entirely homogeneous, and that it would be a Bad Thing if people were forced to make their local nets conform to someone's idea of the Right Way to do their networks. Thus, I have few problems with folks who want to use NATs within their local networks and who understand and accept the limitations of that approach - even though, as you are fond of pointing out, this is an example of a local optimization that is sub-optimal for the global Internet community. OTOH, I have a big problem with constraining and/or encouraging folks to use NATs, while misleading folks about their limitations; and with attempts to make NATs a part of the Internet architecutre and thereby forcing everyone to accept those limitations. Thus we are objecting to much the same thing - not only the attempt to constrain what people can do with their local networks (e.g. preventing folks from getting global addresses) but also the attempt to constrain the kinds of software that people can deploy. Keith
Re: harbinger, Re: [midcom] WG scope/deliverables
* * In other words, that is why the Net never was and resists being be a homogeneous * network. It would be a less efficient design. But the lesson of the Internet is that efficiency is not the primary consideration. Ability to grow and adapt to changing requirements is the primary consideration. This makes simplicity and uniformity very precious indeed. Bob Braden
Re: harbinger, Re: [midcom] WG scope/deliverables
Bob Braden wrote: * * In other words, that is why the Net never was and resists being be a homogeneous * network. It would be a less efficient design. But the lesson of the Internet is that efficiency is not the primary consideration. Ability to grow and adapt to changing requirements is the primary consideration. This makes simplicity and uniformity very precious indeed. Is this now a semantic discussion? Ok, if you want to go than that slope, what I call "efficient design" of course includes "to grow and adapt to changing requirements," "simplicity" and "uniformity". Because "efficient" is all these and more -- efficient is "productive without waste" (Webster). BTW, a design that is too simple is not efficient, because it wastes resources and does not allow what could otherwise be possible. This is the other side of Ockham's razor, when all possibilities are tried in order to find the best one, not just the simplest one. Cheers, Ed Gerck Bob Braden
Re: harbinger, Re: [midcom] WG scope/deliverables
BTW, a design that is too simple is not efficient, because it wastes resources and does not allow what could otherwise be possible. granted that there is such a thing as too simple an answer for most design problems... but one can waste resources and be inflexible much more easily by making a design too complex than by making it too simple. moreover, the limitations of a too-simple design are usually much easier to identify and correct than those of a too-complex design. Keith
Re: harbinger, Re: [midcom] WG scope/deliverables
I too was a strong advocate and strongly disapproved of LANs that were not openly connected with full capabilities to the net, until I had my own home system and discovered that I had no interest in being totally visible and accessible at all times, especially when I was not always around to monitor things. So, now I am very happy behind my little XRouter NAT box, with an ISP service out there where I can have a login shell if I wish. But I do not find any need for a shell account and so do not have one, as long as I have POP or IMAP for my EMail, and an ISP that does not block any of my desired DNS destinations. Lets me sleep well! Without hiring a security staff;-)... But, I also note that I choose this because it is good for me locally, not because I cannot get an IP number for some reason. So, much of this argument appears to be based on the simple fact that IP numbers are scare, and so some companies have chosen to go along with NATS when they have no other reason than the shortage of available IP numbers. If so, then that is the problem to solve and leave those of us who want NATS alone in our happiness;-)... Even with IPV6, I would stay the way I am. In short, not everyone really wants their Internet to be totally homogeneous! Cheers...\Stef At 00:16 -0500 03/02/01, Keith Moore wrote: BTW, a design that is too simple is not efficient, because it wastes resources and does not allow what could otherwise be possible. granted that there is such a thing as too simple an answer for most design problems... but one can waste resources and be inflexible much more easily by making a design too complex than by making it too simple. moreover, the limitations of a too-simple design are usually much easier to identify and correct than those of a too-complex design. Keith
Re: [midcom] WG scope/deliverables
On Thu, 01 Feb 2001 05:34:31 +0100, Sean Doran said: "Hm, now let's see, a router on the 'outside' just sent back this odd ICMP message. Whatever should I do with it?" may not be so Given the unauthenticated nature of ICMP, this should give you pause. I *already* get *enough* headaches with routers and NATs and trying to do PMTU Discovery throught them. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
head hurting [was Re: [midcom] WG scope/deliverables
Well, I don't think this is about midcom any more but something here made my head hurt... Ed Gerck wrote: ... You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders er, that is what the Internet concept was invented for by Pouzin, Cerf and Kahn in the early 1970's. The references are in RFC 1958. That addressing scheme is called IP; the problem is that 32 bits are no longer enough. .and do not require a homogeneous address space to do so. at some level you must have an unambiguous namespace. If 10.1.1.1 is used in two different places there must be a way of distinguishing them. Unfortunately, today we do this without the benefit of an explicit namespace - the distinction is implicit in the instantaneous state of NAT automata, i.e. the internal state of all NATs is an extension to the IPv4 address space. Thus when 10.1.1.1 is behind a NAT that has loaned it address 9.1.1.1, its implicit address is 9.1.1.1+10.1.1.1. That's an unambiguous address space; it's just implicit. (NAPT, multiple NAT or NAT-PT make it a bit more complex, but don't change what I'm saying in principle - the implicit address just gets longer.) A rendez-vous service for NATted peers would have to construct an identifier explicitly, and it might as well be this implicit one. Brian
Re: [midcom] WG scope/deliverables
from some of the discussion, esp. yesterday, i had thoughts of deriving an anti-NAT polemic and posting it. i planned on mentioning all of the other brain-dead, obsolete technologies "we" (IP) had in the past ignored, and how we had triumphed while they had died off. i was thinking of things like IBM mainframes, BSC, SDLC, and ultimately got around to thinking of things "in our community" such as UUCP over asynch (mostly) phone lines, etc. but as i thought of it, i realized that what "we" successfully ignored in the past were things that had little use (the ISO acronym popped up in my mind). things that were heavily used, we somehow brought into the fold and, in some sense, stepped on their shoulders on our way to "the world of greater connectivity". the examples are numerous, and happened in different ways. "we" invented ways of interconnecting (at least at the level of e-mail, the killer app of the 80s) with IBM mainframes, VMS boxes, etc. we ran IP over BSC and SDLC. we invented MX records, as well as bizarre addressing formats (!%.etc.), to interconnect between the SMTP world and the UUCP world. i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. and, that (hopefully), we will achieve the "greater interconnectivity" on top of, and to some extent in spite of NATs. cheers, Greg Minshall
Re: [midcom] WG scope/deliverables
[recipient list trimmed] i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. perhaps. but I note that for many of the examples you quoted, "dealing with them" was not nearly as nice as "not having to deal with them". for instance, having email gateways was clearly better than not having any way to exchange mail between Internet/DECnets/BITNET/uucp/CSnet/etc. at the same time, email gateways never worked as well as we would have liked. they often required users to know arcane details about addressing in foreign email systems and how the addressing from different email systems were combined (things like "ATLAS::BITNET%\"USER@NODE\""@xxx.yyy were entirely too common), they introduced many additional kinds of failure which were difficult to diagnose, non-delivery reports from foreign systems were unreliable (either going to the wrong place or not being able to be returned to the sender) and hard to decipher, and return addresses were often trashed so that replies didn't work. Even the simple question "what is your email address?" was not simple to answer - the answer depended on context, and many users honestly didn't know the answer for anything beyond a very local (to them) context. Many users couldn't give their email addresses to others. I'll also note that email gateways were once ubiquitous, but now are much less common. we do need NATs in IPv4 to work around the address space shortage as well as to allow connectivity for networks using private address space which cannot easily be renumbered, just as we once needed mail gateways. but just like mail gateways, they don't have to stay around forever, and NAT use will also decline when better alternatives are available. Keith (who wrote email gateways in a past life)
Re: [midcom] WG scope/deliverables
Dave Cheriton's TRIAD is an example of such a proposal. Hilarie Dave Crocker [EMAIL PROTECTED] 02/01/01 11:05AM At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ ___ midcom mailing list [EMAIL PROTECTED] http://www.ietf.org/mailman/listinfo/midcom
Re: [midcom] WG scope/deliverables
On Thu, 2001.02.01, Hilarie Orman wrote: Dave Cheriton's TRIAD is an example of such a proposal. Hilarie Dave Crocker [EMAIL PROTECTED] 02/01/01 11:05AM At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. Nimrod, not Triad - fails heterogeneity. -p.
Re: [midcom] WG scope/deliverables
From: Keith Moore [EMAIL PROTECTED] If this group takes the attitude that NATs are inherently broken and that there's really no way to fix them in the long term without phasing out the NAT part, it's much more likely to produce something useful than if it tries to find a way to incorporate NATs into the mainstream architecture of the Internet. Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) You seem to be having problems accepting that fact that NAT's are selling several orders of magnitudes (I'd guess at least 3, but it's probably more) more units than your preferred alternative. Most people would regard this as a sign that the world has decided, and move on. When life gives you lemons, you have to make lemonade. NAT's are a fact of life, and we will, indeed, have to find some way of incorporating them into the mainstream architecture of the Internet. This is a subject on which I have pondered a lot, for several years - maybe you should wrestle with it too. Noel
Re: [midcom] WG scope/deliverables
In message [EMAIL PROTECTED], "J. Noel Chiappa" typed: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) You seem to be having problems accepting that fact that NAT's are selling several orders of magnitudes (I'd guess at least 3, but it's probably more) more units than your preferred alternative. Most people would regard this as a sign that the world has decided, and move on. many nats cost nothin - many are check boxes on existing products - alternatives cost money - some day tho, they may be required like IP was when we started with x.25:-) When life gives you lemons, you have to make lemonade. NAT's are a fact of life, and we will, indeed, have to find some way of incorporating them into the mainstream architecture of the Internet. This is a subject on which I have pondered a lot, for several years - maybe you should wrestle with it too. when life gives you lemons, pick grapes instead and make wine or bottle spring water and sell that (with or without added CO2) its better for your teeth. cheers jon
Re: [midcom] WG scope/deliverables
Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. Thus, while I accept that the market needs a short-term solution to deal with NATs, I also am firmly of the opinion that it's a short-term solution. IPv6 will be attractive for the same reasons that NAT was attractive - it will be the path of least pain to solving a pressing set of problems. Being over-ambitious about goals has prevented more than one working group from accomplishing anything useful, and exhausted lots of talented people in the process. I hardly think that advocating a little restraint in this group's ambition is sufficient justification for personal attacks. Keith
Re: [midcom] WG scope/deliverables
ietf-list folks: Given that a single contribution to a WG's discussion (keeping entirely within the charter) has resulted in multiple personal attacks, I felt compelled to respond to this message. But as this discussion is really specific to the midcom list, I've sent my full reply there. If you're really interested you can read it in the midcom list archives. Unless and until it becomes a process issue, I'd just as soon deal with purely personal disageements in private mail, rather than on the IETF list. Keith --- Keith Moore [EMAIL PROTECTED] wrote: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. ...
Re: [midcom] WG scope/deliverables
Ed Gerck wrote: Keith Moore wrote: I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. NATs are already part of the Internet, and gaining share. An alternate perspective is that the Internet continues to (mostly) work despite the presence of NATs. It is a paradox to begin one standard by selectively omitting current standards (e.g., RFC1122). Joe
Re: [midcom] WG scope/deliverables
Bill Manning writes: | and tosses it w/o any abilitiy to notify the originating | party. Why is it necessary that there be an inability to notify the originating party? dkerr already proved it's cheep cheep cheep to maintain some types of state even with lots of flows per second, and the whole point is to consider ways in which midcom boxes can do speed-smarts trade-offs to help avoid such "inabilities" in the first place. No? "Hm, now let's see, a router on the 'outside' just sent back this odd ICMP message. Whatever should I do with it?" may not be so difficult to answer in a manner different than "ignore it, and hope the sender up eventually stops whatever it's doing to trigger the error message". Translating Mapping Gateways may be "tricky" enough to scare some people, but this is kindergarten compared to this very issue in MPLS... Sean.
Re: [midcom] WG scope/deliverables
The point being that if you have an arbitrary bunch of firewalls and NATs between any two points, then you are forced into telephone-like "call set-up" scenarios, which don't really scale to large groups, specially when the application consists of sporadic messages to arbitrary destinations. or in general, that networked applications sometimes involve more than two parties that are mutually communicating (and they don't necessarily use TCP exclusively) a lot of the proferred solutions seem to assume that pairwise mappings are sufficient; they aren't. Keith
RE: [midcom] WG scope/deliverables
The point being that if you have an arbitrary bunch of firewalls and NATs between any two points, then you are forced into telephone-like "call set-up" scenarios, which don't really scale to large groups, specially when the application consists of sporadic messages to arbitrary destinations. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 6:01 PM To: Bill Manning Cc: Keith Moore; David T. Perkins; Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables e.g. it takes (at least) two to tango... or peer. "at least". yes. Keith
Re: [midcom] WG scope/deliverables
e.g. it takes (at least) two to tango... or peer. "at least". yes. Keith
Re: [midcom] WG scope/deliverables
HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
Re: [midcom] WG scope/deliverables
Keith Moore wrote: I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. NATs are already part of the Internet, and gaining share. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. Now, if you look into the science of Thermodynamics (for example) you will see that this involves a meta-problem that was already solved two centuries ago. NATs are a consequence of a choice rather than makers of a choice. The choice is to use heterogeneous networks. I contend that the reasons for this choice can be found in Nature -- for example, to adapt to local needs without imposing more expensive non-local changes. This is not an Internet phenomenon, it is IMO the reflection of a more general principle. BTW, I agree with Noel's solution that a NAT-haters list might be in order. Maybe you could call it NAT-not list, to avoid the "hate". Meanwhile, the rest of the world would continue to pursue ways to deal with the real-world needs answered by NATs (and things to come). Cheers, Ed Gerck
Re: [midcom] WG scope/deliverables
--- Keith Moore [EMAIL PROTECTED] wrote: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. Well, I (and perhaps many others) respectfully disagree. This is not a short-term solution yet, not until folks have V6 networks deployed. Thus, while I accept that the market needs a short-term solution to deal with NATs, I also am firmly of the opinion that it's a short-term solution. So, if you do agree working that dealing with NATs is a short term solution, why are you so repeatedly trying to torpedo the effort going in to solve the short term problems ? IPv6 will be attractive for the same reasons that NAT was attractive - it will be the path of least pain to solving a pressing set of problems. Agreed, perhaps with the exception of address renumbering. Being over-ambitious about goals has prevented more than one working group from accomplishing anything useful, and exhausted lots of talented people in the process. I hardly think that advocating a little restraint in this group's ambition is sufficient justification for personal attacks. This has been more than just a little advocation of restraint, I might add. Keith ___ midcom mailing list [EMAIL PROTECTED] http://www.ietf.org/mailman/listinfo/midcom Thanks. regards, suresh __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
RE: [midcom] WG scope/deliverables
Would such a rendezvous service work if their were NATs between each of the participants and the service itself (regardless of whether it is hosted on a NAT or not)? If so, wouldn't such a solution alter peer-to-peer to become a hub-and-spoke service requiring ISP mediation in the Internet case as opposed to peer-to-peer? -Original Message- From: David T. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 3:41 PM To: Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
Re: [midcom] WG scope/deliverables
NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
