![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.