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
* 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
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
From: ietf-bounces(_at_)ietf(_dot_)org 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
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>
- The system/network administrators and network architects at
companies/enterprises who are managing and deploying enterprise
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
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
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
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-
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 York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork(_at_)voxeo(_dot_)com
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 mailing list