RE: solution to NAT and multihoming
If you want to be part of the global address space and you are behind a NAT box, get a PPP account outside your NAT box and connect to it with TCP or SSH or SSL or UDP or HTTP or whatever (see for example the use of PPP over telnet, in the www.ora.com Turtle PPP book.) What IPv4 NAT issue doesn't that solve, if any? And for those of you who will claim it is inefficient, just how inefficient is it, in terms of measurable quantities? Whether it costs more than IPv6 over UDP, I don't know, but I strongly suspect that in a vast majority of real-life cases it does not. Cheers, James
Re: solution to NAT and multihoming
"James P. Salsman" [EMAIL PROTECTED] writes: If you want to be part of the global address space and you are behind a NAT box, get a PPP account outside your NAT box and connect to it with TCP or SSH or SSL or UDP or HTTP or whatever (see for example the use of PPP over telnet, in the www.ora.com Turtle PPP book.) That works great for server farms! Great idea! Perry -- Perry E. Metzger[EMAIL PROTECTED] -- Quality NetBSD CDs, Support Service. http://www.wasabisystems.com/
Re: solution to NAT and multihoming
In message [EMAIL PROTECTED], Jon Crowcroft typed: if multihoming is killing routing coz default free zone routers have too many entries and NAT is killing users coz they can't get always on addresses why not have multihomed sites (aren't they usually server/core provider sites) LEASE their standby link address prefixes to access provider sites - and swap the address prefixes when their default link fails and they need to failover to the standby link/addresses... symmetry dictates this ought to work out...and everyone wins by setting uo as a market we could even make the incentives right... i wasn't too clear about this (a bit like my lousy 1000 bit error in the port nat message - that'll teach me to send emails before i've had any coffee:-) so after suitable basting by sean doran, here's the scoop:- I like GSE; however we dont have v6 and we do have NATs; we also have multihoming. 1/ consider global DHCP as a tool, and a mechanism for buying a lease on an aggregate 2/ do NATting on aggregates 3/ design a BGP attribute (yech, i know) to inidcate that an address range is "bank switchable" - this means that it is part of a lease from one AS to another. This means that when told (via management, BGP update, or designated "important" ingress or egress link failure), a pair of domains then bank switch the address range, but enable NATing on the range for exsting flows... got it? j.
Re: solution to NAT and multihoming
Keith, Ed, others... I have been following this entire line of discussion with some amusement and some frustration. I would like to share a couple of humble thoughts on this subject from my own perspective. - yes, NAT in general restricts the applications and/or protocols that can be accessed by users behind the NAT. - yes, having NAT devices deployed will impede development of new protocols and applications that rely on embedding IP addresses. - yes, NAT can be cumbersome in its sustained management as sys admins must punch holes through their various NAT devices to allow a particular application/protocol through. - yes, NAT does violate the global addressibility of Internet hosts. - yes, we could eliminate NAT by giving everyone a globally unique IP address. - no, not everyone wants to run every conceivable application/protocol to their client machines, they are happy with the subset they chose. - no, protocol developers cannot go off developing new protocols that do not consider implications with NAT deployment. - no, not all NAT implementations prevent the use of punch-throughs allowing unique or custom protocols to still work. - no, not everyone wants to participate in the great global address space of the Internet, they just want to access Internet-connected devices. - no, as a mere mortal user, I cannot always obtain real IP addresses as the ISPs claim they must justify IP address assignment and hold them close to their vest pocket. Considering my own company and the plethora of IP-addressed devices, and yes we sit behind NAT and yes I can do nearly all applications and protocols as one can who is not behind a NAT, many of these devices are lab tools that only need connectivity back to an engineer's desk or a shared printer. I don't really need access to a JTAG emulator pod from across the ocean, it just doesn't make sense for my purposes. Given the argument that NAT restricts the available applications and/or protocols, a potential buyer of the device must then choose the one that meets his or her requirements. Since the more restrictive devices will most likely be purchased less and less, and the "better" devices will prevail, will it not be expected that the NAT implementations will improve over time in a manner similar to a farmer improving his crops year after year by only planting the hardiest varieties? So when it comes to buying NAT devices, "buyer beware" should be the mantra of the day. And now the question(s) of the day: What is the solution that can be deployed today or in the next 6 months that will replace the function of NATs in the IPv4 Internet? What about in the next year? 2 years? Respectfully, Kevin Farley __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: solution to NAT and multihoming
Kevin, I don't disagree with most of your assertions, except perhaps one or two. Here's the gap in a nutshell: The fact that NATs are widely deployed means that several quite useful applications are having great difficulty being deployed. You may not think you want to participate in the great global address space, but you might not realize what you're missing as the result of the inability to do so. The market has very limited foresight, which means that it can run into dead ends. The potential market for applications in an IPv6 Internet is far greater than that for a NATted IPv4 Internet, but that doesn't mean that market forces alone will bring about adoption of IPv6. And now the question(s) of the day: What is the solution that can be deployed today or in the next 6 months that will replace the function of NATs in the IPv4 Internet? What about in the next year? 2 years? you can't replace NATs in the v4 Internet. you can however provide new functionality that will allow deployment of applications that won't work in a NATted v4 Internet. - 6to4 lets you tunnel v6 over the existing v4 internet - a IPv6 over UDP tunneling scheme would let you transmit IPv6 over your NATted v4 private network until it got upgraded to transmit v6 natively - extensions to PPP and/or DHCP to request blocks of addresses (rather than just a single address) would allow implementation of the "plug a network anywhere into the network" feature of NATs without actually resorting to address translation - renumbering still needs a considerable amount of work. perhaps we need extensions to routing protocols to advertise upcoming renumbering events (new prefixes become valid in seconds; old prefixes become invalid in seconds, with some reasonable time between the two), with similar extensions to DHCP and to the APIs used by applications. this could all be deployable in 2 years, but the last bit would be tight. the rest could be done much sooner. Keith
Re: solution to NAT and multihoming
Keith, Thank you for your insightful response to my posting. Is it fair to say then, that in the year 2001, there appears to be no widely deployable alternative to NAT? Kevin --- Keith Moore [EMAIL PROTECTED] wrote: Kevin, I don't disagree with most of your assertions, except perhaps one or two. Here's the gap in a nutshell: The fact that NATs are widely deployed means that several quite useful applications are having great difficulty being deployed. You may not think you want to participate in the great global address space, but you might not realize what you're missing as the result of the inability to do so. The market has very limited foresight, which means that it can run into dead ends. The potential market for applications in an IPv6 Internet is far greater than that for a NATted IPv4 Internet, but that doesn't mean that market forces alone will bring about adoption of IPv6. And now the question(s) of the day: What is the solution that can be deployed today or in the next 6 months that will replace the function of NATs in the IPv4 Internet? What about in the next year? 2 years? you can't replace NATs in the v4 Internet. you can however provide new functionality that will allow deployment of applications that won't work in a NATted v4 Internet. - 6to4 lets you tunnel v6 over the existing v4 internet - a IPv6 over UDP tunneling scheme would let you transmit IPv6 over your NATted v4 private network until it got upgraded to transmit v6 natively - extensions to PPP and/or DHCP to request blocks of addresses (rather than just a single address) would allow implementation of the "plug a network anywhere into the network" feature of NATs without actually resorting to address translation - renumbering still needs a considerable amount of work. perhaps we need extensions to routing protocols to advertise upcoming renumbering events (new prefixes become valid in seconds; old prefixes become invalid in seconds, with some reasonable time between the two), with similar extensions to DHCP and to the APIs used by applications. this could all be deployable in 2 years, but the last bit would be tight. the rest could be done much sooner. Keith __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: solution to NAT and multihoming
Thank you for your insightful response to my posting. Is it fair to say then, that in the year 2001, there appears to be no widely deployable alternative to NAT? depends on which aspect of NAT you're thinking of. 6to4 is deployable now. some of the other things could potentially be deployable by the end of 2001. Keith
RE: solution to NAT and multihoming
Wow. After dozens of emails, finally a list of implementable work items that could improve the situation ;) I particularly like the IPv6 over UDP idea, after having encountered several NATs that can't handle anything other than TCP and UDP. Though you've got to be aware of the NAT state timeout issues. To this list, I'd like to add something along the lines of a "NAT requirements" document, specifying the expected behavior of a properly behaving NAT. I think this is useful because in addition to the things that NAT must break due to their fundamental nature, there are lots of other things that they break just because they're badly implemented. It would be great to have an RFC to point to and say "your NAT is violating RFC X -- fix it!" I'd also like to have a NAT MIB that could do things like plumb state for incoming flows, so that there would be a uniform way to enable incoming traffic. But there is more than one way to skin that particular cat. Keith Moore spake thusly: "you can't replace NATs in the v4 Internet. you can however provide new functionality that will allow deployment of applications that won't work in a NATted v4 Internet. - 6to4 lets you tunnel v6 over the existing v4 internet - a IPv6 over UDP tunneling scheme would let you transmit IPv6 over your NATted v4 private network until it got upgraded to transmit v6 natively - extensions to PPP and/or DHCP to request blocks of addresses (rather than just a single address) would allow implementation of the "plug a network anywhere into the network" feature of NATs without actually resorting to address translation - renumbering still needs a considerable amount of work. perhaps we need extensions to routing protocols to advertise upcoming renumbering events (new prefixes become valid in seconds; old prefixes become invalid in seconds, with some reasonable time between the two), with similar extensions to DHCP and to the APIs used by applications. this could all be deployable in 2 years, but the last bit would be tight. the rest could be done much sooner."
RE: solution to NAT and multihoming
Mr. Wood, Philosophically, I agree with your points in the previous email. Reality dictates another perspective. A good philosophy does not necessarily translate to realizable solutions. If this was a discussion on whether or not NAT should be used in the IPv4 Internet, your points would be well taken. As we all know, this is far from the actuality. Your arguments are somewhat like discussing how many smoke detectors to put in a building that is currently burning down. Respectfully, -Larry -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: Friday, January 26, 2001 2:26 PM To: Kevin Farley Cc: [EMAIL PROTECTED] Subject: Re: solution to NAT and multihoming On Fri, 26 Jan 2001, Kevin Farley wrote: - no, not everyone wants to run every conceivable application/protocol to their client machines, they are happy with the subset they chose. you have an interesting spin on 'choice'. How can you choose something before you've tried it? Before it's been written? - no, not everyone wants to participate in the great global address space of the Internet, they just want to access Internet-connected devices. That is tantamount to saying 'We don't need clean air! We don't even want to know what clean air is! We just need to be able to breathe!'. I'm tempted to equate the walled-garden restrictions imposed by NAT with the walled-garden restrictions imposed for copy-protection: http://cryptome.org/jg-wwwcp.htm either way, consumers are disadvantaged. Given the argument that NAT restricts the available applications and/or protocols, a potential buyer of the device must then choose the one that meets his or her requirements. or the requirements of his users. Note the disconnect of needs and interests there. L. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
