Could people who are interested in discussing NAT66 please do so on
the behave@xxxxxxxx mailing list and drop all of these cc:s? You may
not be aware, but you are sending this mail to thousands of people,
and most folks who care about NAT66 are getting this more than once.
People who want to participate in the NAT66 discussion (or just read
it) are encouraged to subscribe to the behave WG mailing list (To
Subscribe: behave-request@xxxxxxxx, In Body: subscribe).
In an attempt to bring the discussion back to the subject at hand...
There is a specific draft for NAT66 that we will be discussing at the
behave WG meeting in Minneapolis:
http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt
Your comments (on the behave WG list only, please) are greatly
appreciated.
Margaret
On Nov 13, 2008, at 2:07 PM, Eric Klein wrote:
Hi Phillip,
On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx
> wrote:
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.
Agreed
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.
NAT is not and never was a security feature, it was a way to use
fewer numbers because they were hard to get. Please stop the falacy
that NAT in any way is related to security, otherwise we would not
need firewalls.
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.
This is not quite true, the ones who have been argueing against it
have constantly asked why we need it. But we still do not know why
we need NAT, no one has done the gap analysis.
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.
This is why I am proposing a wider audience make a decission rather
than having several groups making solutions without understanding
the need.
From: ietf-bounces@xxxxxxxx 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@xxxxxxxx; ietf@xxxxxxxx
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@xxxxxxxxx
> <mailto:townsley@xxxxxxxxx>> 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@xxxxxxxxxxxx
> <mailto:EricLKlein@xxxxxxxxxxxx> 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@xxxxxxxx <mailto:Behave@xxxxxxxx>
> https://www.ietf.org/mailman/listinfo/behave
>
>
> _______________________________________________
> Behave mailing list
> Behave@xxxxxxxx <mailto:Behave@xxxxxxxx>
> https://www.ietf.org/mailman/listinfo/behave
>
>
> _______________________________________________
> Behave mailing list
> Behave@xxxxxxxx <mailto:Behave@xxxxxxxx>
> https://www.ietf.org/mailman/listinfo/behave
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> Behave@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/behave
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf