I beleive that the question would not arise If we had a coherent Internet
architecture
The idea that an application can or should care that the IP address of a packet
is constant from source to destination is plain bonkers. It was no an
assumption in the original Internet architecture and should not be an
assumption that any application should rely on.
If you want to effect a transition from IPv4 to IPv6, the only way to do that
effectively is to design a protocol stack in which the applications simply do
not care whether their packets are routed over IPv4, IPv6 or carrier pidgeon.
NAT66 is in fact a security requirement in many applications and in others it
is a compliance requirement. Stampy feet protests that the idea is profane
don't change those facts.
I know that there are some people in the security area who claim otherwise but
they have been wrong on many issues in the past and they are likely wrong on
this one. Let us consider for a minute the list of real world security measures
that the IETF has successfully deployed, well there is DKIM (sort of) and there
is the post-facto cleanup of SSL after it was successful and the post facto
cleanup of X.509 after that was successful. IPSEC is used as a VPN solution
despite being unsuited for the role as originally designed.
On the negative side the same consensus that opposes NAT66 has in the past
opposed firewalls, the single most widely used network security control. It has
also promoted the idea of algorithm proliferation and negotiation as a good
thing (these days we consider it bad). It has promoted the idea that the most
important feature in a security protocol is that it be absolutely secure
against theoretical attacks rather than easy enough to deploy and use that
people actually use it.
And yes, I have been guilty of many of the same mistakes. But unlike some folk
I am not about to compound that mistake by telling the folk who want NAT66 that
they should visit a re-education camp and unlearn their heretical thoughts.
The only reason NAT is bad in practice is because some people were so opposed
to the concept that they decided it would be a good thing to allow designs that
were purposefully designed to be NAT-unfriendly.
If we don't want to have these discussions on the IETF list we should have a
separate architecture list.
NAT66 is a reasonable protocol proposal to make. If BEHAVE does not like the
idea let the advocates start a new group.
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Mark Townsley
Sent: Thu 11/13/2008 9:10 AM
To: Eric Klein
Cc: Routing Research Group Mailing List; Behave WG; v6ops(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
Eric Klein wrote:
Mark,
I agree with the sentiment, the problem is that the 5 different groups
are doing different things that all relate back to NAT in v6 (rather
than just coexistence) each under their own charter.
I have had suggestions that I bring this to ietf or inter-area mailing
lists for general consensus on a need and IETF overall position prior
to defining a solution.
Behave seems a little limited in scope for the decision about do we or
don't we want to allow any form of native mode NAT into v6.
I agree, and it is not behave's place to make that decision at this
time. I had originally proposed that this be discussed in int-area (if
nothing else because behave's plate is rather full), but some folks
pointed out that some modes may have affects on applications and that
behave was best able to determine that, particularly within context of
the other NATxy work. I'm looking forward to that assessment. So for now
this should remain discussion to understand the problem space and
potential solution space better, not a final referendum on whether or
not the IETF is going to charter work in or otherwise endorse NAT66 in
any manner.
Thanks,
- Mark
Eric
On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley <townsley(_at_)cisco(_dot_)com
<mailto:townsley(_at_)cisco(_dot_)com>> wrote:
I would prefer not to have the same discussion again and again in
multiple places. Let's just try and stick to behave for the
moment, though at some point if the work continues it would need
to be passed around elsewhere. We are not chartering the work one
way or another at the moment, for now this is merely "discussion"
of the topic.
- Mark
Margaret Wasserman wrote:
Hi Eric,
According to the ADs and WG chairs, the correct forum for the
NAT66 discussion is the BEHAVE WG. So, let's discuss it there.
Margaret
On Nov 12, 2008, at 9:44 AM, EricLKlein(_at_)softhome(_dot_)net
<mailto:EricLKlein(_at_)softhome(_dot_)net> wrote:
Cross posted to several lists
Can we keep the NAT66 discussion to less than WGs at a time?
I am trying to keep up with multiple threads on this and
trying to explain that we do not have a valid requirement
for NAT66 defined on any of the mailing lists (v6OPS,
BEHAVE, Softwires, RRG, and now v6).
Le's get this to one group (maybe we need a new mailing
list just for NAT66 discussions, but this is getting out
of hand.
Until now the simple response is that "the IETF does not
support NAT in the v6 architecture." If this needs
changing lets do it right with proper gap analysis and
needs assessment, and then seeing if there is a solution
(several have been proposed that are not NAT) or if we
need to create one, and if those fail then see about
changing the architecture of IPv6.
Eric _______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org <mailto:Behave(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org <mailto:Behave(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org <mailto:Behave(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/behave
------------------------------------------------------------------------
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf