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: ietf-bounces@xxxxxxxx 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 dyork@xxxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf