> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of james woodyatt > Sent: Thursday, October 28, 2010 1:40 PM > To: Roger Marquis > Cc: NAT66 HappyFunBall > Subject: [SPAM] - Re: [nat66] e2e New Version Notification - > Email has different SMTP TO: and MIME TO: fields in the email > addresses > > > On Oct 28, 2010, at 09:47, Roger Marquis wrote: > > > > What's wrong is remote apps that [...] initiate those inbound > > connections to [...] topologies unabstracted by NAT. > > Let's leave aside the parts of your argument I've excised > with ellipses. What precisely is wrong with applications > that expect to initiate flows to destinations in topologies > that have not been obfuscated away by a network address/port > translator? > > This question is relevant to the mailing list topic because > I-D.mrw-nat66 doesn't provide any local topology obfuscation. > I think it would help to understand what you need that the > NAT66 draft as currently composed assumes you're going to get > from somewhere else. > > > -- > > james woodyatt <[email protected]> > member of technical staff, communications engineering > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 >
James, You seem to be changing the context of what Roger wrote, which seemed perfectly understandable and reasonable to me. An application that originates at some arbitrary external location and seeks to cross the Enterprise Network Boundary and arrive at some arbitrary destination internal to the Enterprise without any intervention by the Enterprise Admin to explicitly allow for it has unreasonable expectations as far as the Enterprise (or at least most of them) is concerned. That's exactly the type of scenario most Enterprises DON'T want to see work. In cases of INBOUND connections, Enterprises generally WANT them to fail unless the Enterprise has taken explicit measures to make them work. Furthermore, more often then not, when the Enterprise does want them to work, it's going to FORCE said apps to go through some well known, centrally managed point (i.e. some sort of Proxy/ALG) where it can be monitored/audited/controlled and perhaps some policies regarding how it is being used can be enforced. In other words, NAT generally isn't breaking anything that the Enterprise doesn't want broken anyway.... and may actually be helping to break certain things that would be somewhat more difficult to break without it. This is an area where Enterprises and Transit Providers seem to be entirely different animals with different priorities. Let's look at something like VOIP. From the individual consumers point of view the idea that you can sit down at any internet connection anywhere in the world and have a free/low cost voice conversation with anyone at an internet connection anywhere else in the world is awesomely cool. However from the perspective of many Enterprises this is very problematic for business related calls. Enterprises may require specific things happen in relation to business calls (such as monitoring, auditing, recording) that are infinitely harder to achieve unless such calls are FORCED to go through a central service. So for example, when customer calls up the company and says... "One of your Operators called me up at 2 AM and promised me X". The response from IT isn't.... "OK we'll try to search through every single workstation in the company, including those which are out for repairs, and see If anyone was running Skype at 2 AM....and Oh god, I hope they were following policy and recording the call if they did....and Oh god, I hope someone didn't screw up and let a personal device plug into our network jacks." The response is.... "We have a record of every call originating from our network. Searching the call log db we can see that a call was placed to this number at 5:02 PM from Operator #231 at workstation 211 in the Houston Branch. Here is the voice-recording of the content of that call. Shall I play it for you so that you can hear exactly what was said?" Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
