Hi Hadriel,
I believe I'm the AD you are referring to.
I made the comments as a technical contributor, but also said that my
opinion was informed by discussions within the IESG.
I think your characterization of my comments is a bit incorrect:
"In one of the working group meetings this past week, when the group
was discussing a NAT traversal solution for their new protocol, an A-D
suggested they not spend much time on NAT traversal. He/she indicated
the IESG was discouraging NAT traversal mechanisms for new protocols,
in order to foster demand for IPv6 instead. The A-D further noted
that "we really want it to run over IPv6 more than we want it to run
over IPv4". After being asked for clarification he/she said that "if
you build something that will encourage people to stay on IPv4 longer,
when you send it into the IESG you will get pushback".
I never said "the IESG is discouraging NAT traversal mechanisms for
new protocols,"
The slide being shown differentiated the application from the NAT
traversal mechanism.
If your core protocol (ppsp tracker) ONLY works with a NAT'd transport
(which the slides could be interpreted to mean), I believe you will
get pushback.
My advice at the mic was to build the solution in such a way that it
is "transport agile".
I explicitly made the parallel with the security requirement for
algorithm agility.
The application aspects of the solution should not be dependent on a
NAT-specific transport solution.
I said (feel free to check the session recording, (ch3-fri-am 1:25),
which is where I got the following text from):
"I want to make sure you do not spend a tremendous amount of time
designing something that works for all kinds of NATs, because our
goal is to get rid of NATs [said with a grin]. It's not everybody's
goal obviously. The IESG wants to see the migration to IPv6 completed,
and one of the things that we are seriously pushing back on is
anything that will help you keep NATs around longer so you can keep
IPv4 around longer, because we believe that's a bad solution to the
runout of IPv4 addressing. We recognize that right now you need to
deal with IPv4 networks, so therefore you have to deal with this, but
don't build a lot of assumptions into your core protocol because we
really want it to run over IPv6 more than we want it to run over
IPv4."
and later "we're trying to get people to go to IPv6. If you are
building something that will encourage people to stay on IPv4 even
longer, when you send this into the IESG you will get pushback."
Maybe my language was not as well considered as it should have been,
but it is my understanding that IETF consensus is to have the industry
transition from IPv4 to IPv6.
If your core protocol ONLY works with an IPv4 NAT'd transport, I
believe you will get pushback.
The solution should also be able to work in other environments, such
as an un-NAT'd IPv6 environment.
David Harrington
On Mon, Nov 15, 2010 at 12:19 AM, Hadriel Kaplan
<HKaplan(_at_)acmepacket(_dot_)com> wrote:
Hi,
In one of the working group meetings this past week, when the group
was discussing a NAT traversal solution for their new protocol, an A-D
suggested they not spend much time on NAT traversal. He/she indicated
the IESG was discouraging NAT traversal mechanisms for new protocols,
in order to foster demand for IPv6 instead. The A-D further noted
that "we really want it to run over IPv6 more than we want it to run
over IPv4". After being asked for clarification he/she said that "if
you build something that will encourage people to stay on IPv4 longer,
when you send it into the IESG you will get pushback".
I am not going to name the WG nor A-D, because I'd rather encourage
A-D's to speak their mind, and it doesn't matter who it was. Also,
anyone can make a mistake or be mis-interpreted, and perhaps that's
all this was. (We don't read written prepared statements at the mic,
after all :)
What I'd like to know is the IESG's position with respect to protocols
trying to make themselves work around NATs in IPv4. I'd like to know
if the IESG will push back on new protocols if they attempt to work
around NATs.
I would also like to understand the IESG's position with respect to
IPv6 and whether protocols should not attempt to make themselves work
around potential IPv6 NATs; and more importantly to handle the
possibility that the firewall-type policies which NATs have by nature,
may continue to be used in IPv6 on purpose even if addresses/ports
don't get mapped.
I appreciate the workload you are always under, but I think it's
important for us outside the IESG to know. If this is not the right
medium/process for asking such questions, my apologies... and please
let me know the right way. :)
Thanks,
-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf