There are really two separate questions here: 1) Should application developers write protocols that make assumptions as to the Source/Destination IP headers remaining constant end to end?
2) Should NAT66 be prohibited in order to allow such assumptions to be made? And then there is the question of what NAT66 should look like if it existed which folk can take to BEHAVE. >From the application protocol developer point of view: * The existing network does not allow for the assumption to be made * There is no real benefit to allowing the assumption to be made * If I see a protocol that makes such an assumption I consider it HISTORIC [as per BCP9] * If I see a protocol proposal that makes such an assumption I consider it BROKEN [as per PHB] I really do not see a mass of application developers who are chomping at the bit to develop protocols with this type of assumption. There are folk who want to get around the inbound connection filtering that is a byproduct of NAT. But that is going to remain regardless. We need a means of securely communicating inbound port requests and that needs to be independent of the IP transport and IP address mapping. Given that there is no demand from the application developers, the second question must fall. The insistence on prohibiting NAT66 is not driven by application developer concerns as has been repeatedly asserted. We know we are going to have to deal with NAT44, NAT64 and NAT46 for the foreseable future. The portion of the Internet where we can assume IPv6-6 to be supported without mapping is negligible and will not be close to a workable assumption for decades. The reaction to NAT66 is exclusively driven by network layer concerns. It is not an architectural assumption that modern application designs exploit or could exploit if they wanted to. If folk want to make a network argument against NAT66 then please go away to BEHAVE. But if we have a case where the applications world is being cited as the source of a requirement and the applications world is saying that it is not so, this is the forum for that discussion. I suggest that the only circumstance in which this discussion is worth continuing in any forum is if the opponents can identify an application where : 1) The constant IP address assumption is required for any reason other than enabling an inbound connection to be made. 2) There is no acceptable means of implementing the requirement that does not rely on the assumption -----Original Message----- From: [EMAIL PROTECTED] on behalf of Dan York Sent: Mon 12/1/2008 5:27 PM To: Keith Moore Cc: 'Cullen Jennings'; 'behaveietforg WG'; 'IETF Discussion'; 'Ned Freed'; 'Eric Klein'; 'IESG IESG'; 'IAB'; 'Fred Baker (fred)' Subject: Re: where to have the NAT66 discussion (was Re: [BEHAVE] Please movethis thread to BEHAVE mailing list ... ) I would suggest that there is at least one other block of people who are missing from the list of stakeholders in the "To NAT or not to NAT in IPv6" discussion that Keith Moore listed: On Dec 1, 2008, at 3:52 PM, Keith Moore wrote: > - The greatest concentration of NAT experts in the IETF are probably > in > the BEHAVE group. <snip> > > - Some of the pressure to have NATs (other than for IPv6 transition) > seems to be coming from routing area people <snip> > > - Other pressures to have NATs are from network operators <snip> > > - And of course we also need input from applications people. <snip> .... namely: - The system/network administrators and network architects at companies/enterprises who are managing and deploying enterprise networks. I don't know how well this particular group is represented within the IETF. I know there are some people from that group at IETF meetings because I've met a few. But only a few. My sense from interacting with a good number of them over the past 10 years or so is that they are probably way too busy dealing with their networks to be involved with what goes on here inside of the IETF. In fact, in some conversations over the years where I brought up the IETF with some folks in the sys/ netadmin space, the IETF (if it was known, which was not always the case) was this vague amorphous body out there "making standards". But that was it. Relevance of the IETF to their daily job was viewed as slim to none. Now this group is also the group setting up enterprise networks, allocating IP addresses, deploying infrastructure, etc. And they pretty much all use NAT. And the ones I've talked to all *like* NAT. Sure, they have to use NAT with IPv4 in many/most network situations, but I've known of companies with large IPv4 address blocks (unfortunately the names escape me right now) who *chose* to use NAT and RFC1918 addresses and to not use much of their large IPv4 blocks internally. Why? Control. As has been pointed out by others in this thread, there is immense value to a company/organization/entity in maintaining control over their IP addresses. They are not locked into their current ISPs... with a sufficient amount of randomness they can hopefully easily integrate with other acquisitions... they don't have to renumber, etc., etc.... the various reasons people have pointed out. I personally don't see them ever giving up NAT. Oh, we can point out how broken it makes their networks... we can point out how IPv6 apps will work so much better without NAT.... we can point out how ULA and RFC 3484 make NAT unnecessary. Some will listen. Some will use ULAs and put in place the appropriate routing policies, etc. to make it all work. Others - and I personally think it will be *most* - will simply just NAT their IPv6 network just exactly like they did for their IPv4 network. Why? Because it's simple and easy and **that's what they know**. They maintain all the control they want. They have even fewer external IP addresses to think about (just the ones on the NAT boxes). Many view NAT as part of a security plan with topology-hiding, etc. (And yes, we can argue debate that point endlessly, too.) To them, it makes their lives simpler, reduces the workload they have, etc., etc. We can argue that they shouldn't think this way... that with IPv6 they have a new and better way to do things... but these are the same folks who are just-trying-to-keep-their-networks-running-while-not-having- their-jobs-outsourced-as-their-budgets-are-being-cut-and-they-just- want-to-keep-things-stable-while-the-idiot-on-the-second-floor-keeps- losing-their-system-password-and-the-turkey-on-the-third-floor-has- somehow-deleted-their-critical-document-for-the-zillionth-time-and-the- marketing-people-want-web-2.0-apps-implemented-yesterday-and-the-CFO- is-demanding-better-realtime-stats-and-oh-by-the-way-another-company- was-just-acquired-and-needs-their-network-to-be-integrated-and-the- pager-going-off-at-2am-every-night-this-week-is-getting-really-really- old-and....and....and...and...and-now-the-CIO-says-that-we-have-to- have-IPv6-addresses-deployed-by-next-month... I think NAT will go away for these folks when we pry the cold dead fingers of the last sysadmin away from the keyboard... I'd love to be wrong on this, but I think a great number of enterprise IT folks actually like NAT and will continue to use it even as they move into IPv6. Our choice within the IETF seems to me to be either ignoring it entirely and hoping that somehow all these networks will "see the light" and embrace networks without NAT - or alternatively to come up with ways that NAT can work in IPv6 spaces (while still encouraging people to look more at how to deploy without NAT). And to return to my original point, I think we need to see if there are ways to include more people from the actual system/network admin sphere into these discussions.... (unless I'm wrong and that segment is already very well represented and I just haven't noticed)... because at the end of the day, *they* are the ones who are actually going to be implementing (or not) all these standards we create. My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
