NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.
Recently, there has been some discussion of network address with
IPv6::IPv4 protocol translation. Some have referred to that as
NAT-PT also, which can be
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed [1],
it seems doubtful that it would be worthwhile for any of the
operators who have deployed NAT+PT to travel to an IETF for
the purpose of commenting in person.
A proposal for the TLS authorization standard from RedPhone Security,
for which RPS has applied for a patent, has already been rejected for
official standardization. However, RPS is now trying to circumvent the
(very well-advised) standing no-patent policy by submitting is for
consideration as an
On 14 nov 2007, at 14:19, RJ Atkinson wrote:
There is an opportunity in all of this mess for some folks
to initiate work to develop a replacement RFC for NAT+PT. As near as
I can tell, operators aren't particularly worried whether that RFC
is on the standards-track or not, but they do
Sam Hartman wrote:
Romascanu, == Romascanu, Dan (Dan) [EMAIL PROTECTED] writes:
-Original Message- From: Sam Hartman
[mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 10:24
PM To: Leslie Daigle Cc: IESG; ietf@ietf.org; [EMAIL PROTECTED]
Subject: [PMOL]
Ran,
it seems doubtful that it would be worthwhile for any of the
operators who have deployed NAT+PT to travel to an IETF for
the purpose of commenting in person.
There's also e-mail. And some of us in the IETF and the management
thereof do travel to operator meetings. But yes, understanding
From: RJ Atkinson [mailto:[EMAIL PROTECTED]
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed
[1], it seems doubtful that it would be worthwhile for any of
the operators who have deployed NAT+PT to travel to an IETF
In your previous mail you wrote:
In any event, Alain Durand (Comcast) has just posted
an I-D with some requirements in this area. He also made a public
presentation asking for NAT+PT at the last NANOG. (I believe his
NANOG presentation is available online in PDF; it was a
On Wed, 14 Nov 2007, Iljitsch van Beijnum wrote:
On 14 nov 2007, at 14:19, RJ Atkinson wrote:
There is an opportunity in all of this mess for some folks
to initiate work to develop a replacement RFC for NAT+PT. As near as
I can tell, operators aren't particularly worried whether that
On 14 nov 2007, at 16:53, Lucy Lynch wrote:
There are several collection efforts going on - you might take a
look at:
http://www.civil-tongue.net/clusterf
http://www.ipv6-to-standard.org/
Don't bother. The first one is just a big stack of loose associations
with IPv6 that don't make
RJ Atkinson a écrit :
NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.
Recently, there has been some discussion of network address with
IPv6::IPv4 protocol translation. Some have referred to that as
--On 14. november 2007 07:46 -0500 RJ Atkinson [EMAIL PROTECTED]
wrote:
NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.
Recently, there has been some discussion of network address with
IPv6::IPv4
As far as I'm concerned, NAT-PT is defined in RFC 2766, and describes a
particular way of translating between IPv4 and IPv6. If people are
using NAT-PT in a different way, that's unfortunate. But I don't
consider it a major problem because NAT-PT really isn't usable anyway,
for two sets of
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to
continue to be for the forseeable future.
I suspect that most desktop users do not need hardware crypto for
performance. Irarely if ever drive my GiGE
Thus spake RJ Atkinson [EMAIL PROTECTED]
NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.
I have never seen NAT-PT used to refer to that; the common terms are NAT and
NAPT, though at least one vendor I'm
Alain Durand proposed in 2002 :
- NAT64 for IPv6 - IPv4
- NAT46 for IPv4 - IPv6
Practically speaking, any box that translates between v4 and v6 has to
be able to translate in both directions. Which side is to and which
is from then? You don't want to make the assumption that the apps are
Hi, Steve,
Stephen Kent wrote:
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to continue
to be for the forseeable future.
I suspect that most desktop users do not need hardware crypto for
I am in agreement with Keith here, I don't think the names are helpful.
What I want is a network protocol transition box, the ANYBOX which:
1) Bridges a local network A to the Internet B
2) Can accept either IPv4 or IPv6 on either side of the box
3) Provides seamless Internet connectivity for
On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent [EMAIL PROTECTED] wrote:
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to
continue to be for the forseeable future.
I suspect that most desktop users
Hi, Steve,
Steven M. Bellovin wrote:
On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent [EMAIL PROTECTED] wrote:
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to
continue to be for the forseeable
On Wed, 14 Nov 2007 21:22:48 -0500
Sam Hartman [EMAIL PROTECTED] wrote:
Joe By essentially shutting your machine down for over an hour.
No, not at all; not even close.
I'm only going to send this one message, but then I'll drop out of the
thread. We've drifted far from Leslie's
Joe == Joe Touch [EMAIL PROTECTED] writes:
Joe Hi, Steve,
Joe Steven M. Bellovin wrote:
On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent [EMAIL PROTECTED] wrote:
Joe,
I disagree with your suggestion The software performance of
security protocols has
Ran,
On Wed, Nov 14, 2007 at 08:19:56AM -0500, RJ Atkinson wrote:
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed [1],
it seems doubtful that it would be worthwhile for any of the
operators who have deployed NAT+PT
Sam Hartman wrote:
...
Yes, Steve almost certanily did slow down any heavy CPU use during the time
when he was doing the backup.
Our point--Steve, Steve and I--is that for a lot of uses and a lot of
users, no one cares.
Perhaps that's why everyone is using security. We don't have a problem
Rémi Després wrote:
Keith Moore a écrit :
Alain Durand proposed in 2002 :
- NAT64 for IPv6 - IPv4
- NAT46 for IPv4 - IPv6
Practically speaking, any box that translates between v4 and v6 has to
be able to translate in both directions. Which side is to and which
is from then?
Keith Moore a crit:
Alain Durand proposed in 2002 :
- NAT64 for IPv6 - IPv4
- NAT46 for IPv4 - IPv6
Practically speaking, any box that translates between v4 and v6 has to
be able to translate in both directions. Which side is "to" and which
is "from" then? You don't want
Within IPv6 research society, we have used the NAT-PT term for years. For my
concerned, there is no confusion at all. However, it may be confusion for
the others outside IPv6 research society. They may use the term in different
way, such as translation between others protocol rather than
The IESG has received a request from the Mobility for IPv4 WG (mip4) to
consider the following document:
- 'Mobile IPv4 Traversal Across IPsec-based VPN Gateways '
draft-ietf-mip4-vpn-problem-solution-03.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final
A new IETF working group has been formed in the Operations and
Management Area. For additional information, please contact the Area
Directors or the WG Chairs.
+++
Performance Metrics at Other Layers (pmol)
===
Current Status: Active Working Group
WG
29 matches
Mail list logo
