Sam,
I disagree with this characterization of the document. I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work. Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a
On 2007-02-28 17:02, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get rid of
NAT rather than trying to make NAT work.
This is startlingly irrelevant to the present document. We have a large corpus
of documents about the issues caused by NAT
Fred Baker writes:
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get
rid of NAT rather than trying to make NAT work.
...
Actually this has already been done, please see draft-ietf-v6ops-nap-06.txt
which has
I think it's important to publish this document, to make it
clear why NAT-PT is a solution of very dubious value.
Brian
On 2007-02-27 20:14, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Reasons to Move NAT-PT
Just to clarify the current situation...
The statement below says that the recommendation is for RFC 2766 to be
reclassified to experimental.. As is implied by the title of the draft,
it actually recommends reclassification to Historic.
This error results form a piece of history ;-) - The
The core assumption here seems to be that NAT is a bad thing so lets get rid of
NAT rather than trying to make NAT work.
The last time I heard that it was in IPSEC One objection is that IPSEC is not
NAT-friendly, some of us consider that a feature not a bug. The result was an
IPSEC
Good catch - that seems to be a little obsolete text that's
sitting around in the I-D tracker. The draft itself is
clear that Historic is the intention.
Brian
On 2007-02-28 15:07, Elwyn Davies wrote:
Just to clarify the current situation...
The statement below says that the recommendation
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, The core assumption here seems to be that NAT is a
Hallam-Baker, bad thing so lets get rid of NAT rather than trying
Hallam-Baker, to make NAT work.
I disagree with this characterization of the
On Wed, Feb 28, 2007 at 05:12:45PM +0100, Brian E Carpenter wrote:
Good catch - that seems to be a little obsolete text that's
sitting around in the I-D tracker. The draft itself is
clear that Historic is the intention.
For your information:
I have asked the secretariat to reissue the Last
Sam,
On Feb 28, 2007, at 8:37 AM, Sam Hartman wrote:
I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work. Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a different
Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get rid of
NAT rather than trying to make NAT work.
NAT-PT is not NAT. It does a whole lot more, but it *cannot* do what it
claims to do completely, because the semantics on the two sides
Is there a document that describes a deployment plan under a two stack
transition?
I am somewhat uncomfortable moving documents to historic just because they
contain ideas we find unpleasant. And in particular I would rather see
documents that say 'this is how to solve a problem' rather than
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so
lets get rid of NAT rather than trying to make NAT work.
...
The only protocol which really cares about the source and
destination IP addresses is IPSEC and we have
On Feb 28, 2007, at 12:40 PM, Hallam-Baker, Phillip wrote:
Is there a document that describes a deployment plan under a two
stack transition?
Well, I can't say they are exacty what you're looking for, but you
might glance at:
http://www.ietf.org/rfc/rfc2767.txt
2767 Dual Stack Hosts
From: Fred Baker [mailto:[EMAIL PROTECTED]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad
thing so lets
get rid of NAT rather than trying to make NAT work.
...
The only protocol which really cares about the source
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing
so lets get rid of NAT rather than
On Wed, 28 Feb 2007 20:42:04 -0500
Sam Hartman [EMAIL PROTECTED] wrote:
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED]
writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption
From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]
More precisely, any protocol that uses secondary connections,
the parameters of which are carried in-band in a secured
connection, can't easily be NATted. The most obvious example
is FTP. 4217 notes that it only works through NAT if
Steven == Steven M Bellovin [EMAIL PROTECTED] writes:
Steven On Wed, 28 Feb 2007 20:42:04 -0500
Steven Sam Hartman [EMAIL PROTECTED] wrote:
Hallam-Baker, == Hallam-Baker, Phillip
[EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On
At 6:31 PM -0800 2/28/07, Hallam-Baker, Phillip wrote:
This is a design choice in the protocol, one that I would see as a layering
violation. Application layer protocols should not be talking about IP
addresses.
Network management protocols are arguably at the application layer (and
they
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Reasons to Move NAT-PT to Historic Status '
draft-ietf-v6ops-natpt-to-historic-00.txt as an Informational RFC
This document recommends that the IESG reclassifies RFC 2766 from
Standards
21 matches
Mail list logo
