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 to
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 dr
etf.org
> Cc: v6ops@ops.ietf.org
> Subject: Re: Last Call: draft-ietf-v6ops-natpt-to-historic
> (Reasons to Move NAT-PT to Historic Status) to Informational RFC
>
> I think it's important to publish this document, to make it
> clear why NAT-PT is a solution of very dubious va
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 t
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 s
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 are
ll: draft-ietf-v6ops-natpt-to-historic
> (Reasons to Move NAT-PT to Historic Status) to Informational RFC
>
> 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
>
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 disc
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 usin
> 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 abou
> "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 r
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:
> >
> 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
> "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 [mail
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 ce
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 diff
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 b
20 matches
Mail list logo