A new sysadmin has recently joined the company where I work (I am a
software engineer and part-time sysadmin). As he's the only full-time
sysadmin here, the network now falls under his purview. Today he
showed me his plans for reorganisation of the network, and they involve
introducing NAT on a
Zefram writes:
My question for the list is is there a web page or
other document anywhere that comprehensively states
the case against NAT?
If your new administrator is of the type who fixes things that aren't
broken, it may be the admininistrator that needs replacement, not the
network
Yeah, but this was the point. Where is the community consensus
document that says all this?
Spencer
- Original Message -
From: Anthony G. Atkielski [EMAIL PROTECTED]
To: IETF Discussion [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 6:55 AM
Subject: Re: arguments against NAT?
And, to follow up on my own posting (sigh), RFC 3235 and 3027 are
Informational... we have no STD, and no BCP, that come up when you
search for NAT or Network Address Translator, so... perhaps there is
no community consensus document that says what the community consensus
appears to be, and the
On Tuesday, December 2, 2003, at 08:22 AM, Spencer Dawkins wrote:
Yeah, but this was the point. Where is the community consensus
document that says all this?
3235 goes into some of it, albeit from an application perspective.
2993 does as well, but at three years old it's already slightly
outdated.
Spencer Dawkins wrote:
Yeah, but this was the point. Where is the community consensus
document that says all this?
RFC 2993 is the closest thing I could find to what I want, and it's
rather good (thanks Tony), so it's at the top of the reading list I've
sent to the new sysadmin. I'll be
I've argued strongly against NAT, but he's one of those people who seem
to be willing to accept arbitrary amounts of pain (we don't need to
use [protocols that put IP addresses in payload], timeouts aren't
a problem). I'm now pointing him at some relevant RFCs. My question
for the list is is
Spencer Dawkins writes:
... perhaps there is no community consensus document
that says what the community consensus appears to be ...
I don't believe there is any consensus. I'm among those who don't like
NAT, considering it only an occasional, necessary evil.
Melinda Shore wrote:
although frankly this is one particular area where
there's a clear and growing divide between this
community and the network administrator community
(particularly enterprise and residential).
Because this community has long ignored real problems and followed the
lead of
On Tuesday, December 2, 2003, at 10:44 AM, Michel Py wrote:
Because this community has long ignored real problems and followed the
lead of protocol fanatics or rhetoricians that for the sake of
technical
elegance design protocols and architectures that look real nice on
paper
and don't solve
Zefram,
Our take on why NATs are bad is at:
http://dsonline.computer.org/0207/departments/wp4icon.htm
And our method for undoing what a NAT does, called TetherNet is at:
http://www.isi.edu/tethernet and paper about it is at:
http://www.isi.edu/touch/pubs/discex03-tethernet/
(Contact me if you
...
I've argued strongly against NAT, but he's one of those people who seem
to be willing to accept arbitrary amounts of pain (we don't need to
use [protocols that put IP addresses in payload],
how about DNS? two of the extra years that got tacked onto the decade
of DNSSEC were due
Anthony G. Atkielski wrote:
NAT has obvious disadvantages. ...
... Chat and instant messaging services will fail, and there is no
way to get them to work with NAT.
So far I have not been able to get chat or instant messages services to
fail because
of NAT. (Not that I am saying that NAT is
Doug Royer wrote:
Anthony G. Atkielski wrote:
NAT has obvious disadvantages. ...
... Chat and instant messaging services will fail, and there is no
way to get them to work with NAT.
So far I have not been able to get chat or instant messages services to
fail because
of NAT. (Not that I
Melinda Shore wrote:
...
I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs. I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and
Keith Moore writes:
This was shortsighted, just like having the notion of class built into
IPv4 addresses was shortsighted.
Just about everything about address allocation has always been
shortsighted.
I have a simple idea: Why not just define the first three /32 chunks of
the IPv6 address
Schiro, Dan writes:
This is a dangerous prospect. The company I work for makes a networking
stack and our IPv6 implementation expects the lower 64 bits to be the unique
interface identifier.
Does anyone see how wasteful this is? What's the likelihood of having
2^64 unique interfaces in the
On 2-dec-03, at 20:42, Schiro, Dan wrote:
Fortunately the mistake is easily rectified, so long
as software doesn't get into the habit of expecting the lower 64 bits
of an address to be a unique interface identifier.
This is a dangerous prospect. The company I work for makes a
networking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On fredag, nov 28, 2003, at 20:10 Europe/Stockholm, Anthony G.
Atkielski wrote:
Ah, I see what you mean now. However, the devision is a done deal as
RFC 3513 mandates that all unicast IPv6 addresses except the ones
starting with the bits 000
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The post KPQuest updates are a good example of what Govs do not want
anymore.
I can't make this sentence out. Do you mean the diminish of KPNQwest?
In that case, please explain. And before you do: I probably know more
about KPNQwest than anyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This being said, I note that this thread is only oriented to
prospective numbering issues. May I take from that that none of the
suggested propositions rises any concern ?
In particular, that there is no problem with two parallel roots file
if
On 2-dec-03, at 21:04, Anthony G. Atkielski wrote:
Why dedicated /64 to anything? We are getting by just fine on /32 for
the whole world right now. Why is a sudden expansion of 2^32 required
RIGHT NOW?
Stateless autoconfiguration.
See, that's the classic mistake: Everyone wants to divide the
On Tue, 2 Dec 2003 [EMAIL PROTECTED] wrote:
The 61st IETF meeting will be held over the dates of November 7-12, 2004.
The location has not been finalized.
How about Minneapolis!
At least there's a Subway nearby, and no need (or even desire) to go
outside :-)
--
Pekka Savola
There is ample precedent for confusion here. Most applications that
want to make use of MIME media types will want at least form #2, but
naive implementors may stop at type/subtype and ignore parameters. In
particular, I think JSR 168 (the portal/portlet specification) is going
to have to be
Bob Hinden writes:
It was well understood that it was important to keep most of the IPv6
address space open to allow for future use.
Why do we need 42,535,295,865,100,000,000,000,000,000,000,000,000
addresses right now, then?
Kurt Erik Lindqvist writes:
so you are making claims and comments on something you don't even have
bothered to read the basic documentation on. Wow.
Wait twenty years, and we'll see who's surprised.
Iljitsch van Beijnum writes:
About 85% of the IPv6 address space is specifically left unused at this
time. And even within the 2000::/3 which is defined for global unicast
use *now* just 3/8192th is really used.
But that represents 5,192,296,858,530,000,000,000,000,000,000,000
addresses. Why
My question
for the list is is there a web page or other document anywhere that
comprehensively states the case against NAT?
Because until recently there was a widespread belief that we were stuck with
NAT and might as well make the best of it, and that we couldn't make the best
of it if we
RFC 3513 mandates that all unicast IPv6 addresses except the ones
starting with the bits 000 must have a 64-bit interface identifier in
the lower 64 bits.
This was shortsighted, just like having the notion of class built into
IPv4 addresses was shortsighted. People are going to need to
Keith,
Fortunately the mistake is easily rectified, so long
as software doesn't get into the habit of expecting the lower 64 bits
of an address to be a unique interface identifier.
This is a dangerous prospect. The company I work for makes a networking
stack and our IPv6 implementation
Fortunately the mistake is easily rectified, so long
as software doesn't get into the habit of expecting the lower 64 bits
of an address to be a unique interface identifier.
This is a dangerous prospect. The company I work for makes a networking
stack and our IPv6 implementation
Putting a crypto-based host identifier in the address is unnecessary,
since there's really no need to include a strong host identifier in
every packet sent to a host. The locator alone is usually sufficient,
and if that's not sufficient, the sender can generally encrypt the
traffic
On 2-dec-03, at 20:03, Keith Moore wrote:
RFC 3513 mandates that all unicast IPv6 addresses except the ones
starting with the bits 000 must have a 64-bit interface identifier in
the lower 64 bits.
This was shortsighted, just like having the notion of class built
into
IPv4 addresses was
Iljitsch;
Putting a 64-bit crypto-based host identifier in the bottom 64 bits of
IPv6 addresses shouldn't get in the way of regular IPv6 addressing
mechanisms and/or operation.
Putting a crypto-based host identifier in the address is unnecessary,
since there's really no need to include a strong
[EMAIL PROTECTED] wrote:
The 61st IETF meeting will be held over
the dates of November 7-12, 2004.
The location has not been finalized.
Pekka Savola wrote:
How about Minneapolis!
:-D
At least there's a Subway nearby,
There is also an excellent steak house just the other side of the
On Wed, 2003-12-03 at 08:27, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What would be the difference if the ccNSO resulted from an MoU? It
would permit to help/join with ccTLDs, and RIRs, over a far more
interesting ITU-I preparation. I suppose RIRs
Melinda,
Melinda Shore wrote:
The problems we're seeing from NATs - and they're considerable
It depends of the situation; don't generalize, the reality of numbers is
against you. The number of sites where NAT works just fine is orders of
magnitude greater than the number of sites where it
Joe Touch wrote:
Since we've been lacking a similar non-NAT solution,
we (ISI) built one called TetherNet, as posted earlier:
http://www.isi.edu/tethernet
What is this beside a box that setups a tunnel? What's the difference
with:
Michel Py;
Melinda Shore wrote:
The problems we're seeing from NATs - and they're considerable
It depends of the situation; don't generalize, the reality of numbers is
against you. The number of sites where NAT works just fine is orders of
magnitude greater than the number of sites where it
39 matches
Mail list logo
