Subject: Number of Firewall/NAT Users

From: Jiri Kuthan <[email-masked]>
Date: Sat, 20 Jan 2001 07:58:52 +0100

Hello,

is anyone aware of any estimations of fraction of Internet users
who are behind firewalls and NATs?

Thanks,

Jiri

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 20 Jan 2001 06:47:24 -0800

The fraction of consumer users behind NATs is largely
limited by the number of multiple PC households. As
of 2000, my understanding is that 27 percent of
households have multiple PCs. Of those households
with multiple PCs, only a fraction are networked. 

This would indicate that perhaps less than 10 percent
of all consumer households are behind a NAT today. This
may translate to a larger fraction of consumer
PCs because multiple PC households have
more PCs (duh). 

Over the next few years, it is likely that the
NAT penetration will increase dramatically, 
driven by increases in the number of multiple
device households (not just PCs), as well as
deployment of broadband technologies such
as ADSL modems, which frequently ship with 
NAT capabilities.  

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]]
Sent: Friday, January 19, 2001 10:59 PM
To: [email-masked]
Subject: Number of Firewall/NAT Users

Hello,

Thanks,

Jiri

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.

---

From: vint cerf <[email-masked]>
Date: Sat, 20 Jan 2001 11:10:48 -0500

what about business users, bernard?

vint

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Sat, 20 Jan 2001 14:39:43 -0800 (GMT-0800)

> what about business users, bernard?

My understanding is that the fraction of enterprises deploying NAT is 
much larger than in consumer households. Almost all commercial firewall 
products now support NAT. In comparison, fewer firewall products support 
competing approaches (such as SOCKS, or RSIP). 

And of course, as the address space continues to run out it is likely 
that enterprise and perhaps even ISP NAT deployment will increase 
substantially over the next few years. 

What is worth thinking about is what this will imply for the future 
internet architecture. It is one thing to address issues brought up by a 
single well functioning NAT within the same administrative domain. It is 
another thing to deal with multiple layers of perhaps not so well 
implemented NATs which may not even support tunneling of IPv6. 
And that is where we appear to be headed over the next few years.

---

From: vint cerf <[email-masked]>
Date: Sat, 20 Jan 2001 17:16:52 -0500

a nightmare it seems to me

v

---

From: "Jim McMurry" <[email-masked]>
Date: Sat, 20 Jan 2001 14:38:53 -0800

Then it seems we will have to create an ever expanding bandwidth to support
all the overhead associated with NAT and these multiple layers.

If not we could wind up with OC-192's that feel like 56k modems :(

Jim McMurry

---

From: Ed Gerck <[email-masked]>
Date: Sat, 20 Jan 2001 15:34:10 -0800

> And that is where we appear to be headed over the next few years.

More than an year ago I commented here that  NATs can help IPv6
interoperate... so, they are by definition, useful.   I also suggested we
don't yet  have a "NAT model", in engineering sense, where a model
fits in a larger model and so on. All we have is a "NAT hack", but this
does not mean that NATs are hacks (though they sort of rhyme).

Technically, a NAT box  is used to interconnect two (or more) independent
networks so that hosts in the networks can communicate with one another
*without any change* to the respective networks, usually by means of a
programmable device that performs automatic address translation in
transmission and/or address and name translation in reception for each
formatted message.  This is benefitial not only to provide Internet routing to
near unlimited addresses in private networks but also for address hidding,
privacy and flexibility.

So, maybe this is what the market really wants -- a multiple-protocol Internet,
where tools such as NAT boxes for firewalling, privacy, address extension and
IPv4/IPv6 interoperation will be needed ... and valued.  The lesson is that the
Internet does not have to be a homogenous network, it can be a heteregenous
network with IPv4/NAT/IPv6. Since a heterogeneous network can use local
solutions for local problems, I believe Internet users will continue to prefer
local flexibility.

Comments?

Cheers,

Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Sat, 20 Jan 2001 18:56:50 -0500

> all the overhead associated with NAT and these multiple layers.

bandwidth consumption is the least of the problems. 

actually NATs probably conserve bandwidth because they prevent many kinds
of new applications from being deployed.

Keith

---

From: Matt Holdrege <[email-masked]>
Date: Sat, 20 Jan 2001 16:48:43 -0800

>all the overhead associated with NAT and these multiple layers.

The overhead comes in the form of complexity rather than bandwidth.

But complaining about NAT is not a new fad and usage of NAT hasn't been 
stemmed the tiniest bit. We can't keep burying our heads in the sand and 
trying to deny new work on dealing with NAT. It's here, it isn't going away 
and we have to find solutions for applications that need to deal with NAT.

Work in this area is starting in the new MIDCOM working group. But some 
people are still worried about being politically correct with respect to 
denying the perceived legitimacy of NAT. I think we need to go full force 
in finding solutions in an open standards group rather than having a closed 
group solve the problem in an inelegant fashion.

---

From: Richard Shockey <[email-masked]>
Date: Sat, 20 Jan 2001 21:32:35 -0500

>a nightmare it seems to me

simply put and well stated..but I do suspect that the current NAT problem 
can be solved by the proper deployment of applications that MUST have 
routeable addresses. SIP being a case in point. The promise of SIP is a 
global end to end realtime messaging media ( text, voice , video ) as a 
complement to the store and forward Universal Messaging media based on SMTP 
( text, voice, fax) we have now.

If the application is powerful enough end users will force their networks 
to adapt accordingly.

The Net as we know is has always been application driven. SMTP, HTTP, FTP 
etc. These applications can transverse NAT's but real forms of streaming 
media cannot.

If we build the right applications that the market wants.. the networks 
will adapt to the needs of the applications....not the other way around.

Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: [email-masked]
Date: Sat, 20 Jan 2001 22:24:49 -0500

> etc. These applications can transverse NAT's but real forms of streaming 

OK.. I'll admit that streaming stuff isn't my strong point, and I'm down with
the flu to boot, so my clue level is pretty low here.. but...

Is it SIP that cannot work across a NAT, or is there a generic reason that
*no* streaming-media protocol can work across a NAT?

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Jan 2001 23:13:06 -0500

There are two somewhat separable issues:

- Unless you only want to make outbound calls, SIP user agents have to
be "servers" as well as "clients". Without per-application hacks, NATs
don't work with inbound connections, so SIP gets bitten by that. (There
are kludges around that, such as a permanent connection to an
outside-the-NAT box that serves as the point of contact.) This is an
example of the general problem of the NAT worldview that users behind
NATs only run clients.

- Real-time media applications use UDP, but without being a
request-response protocol. Without an ALG, NATs don't work here. (One
should be somewhat careful to distinguish streaming and real-time media
applications, as their requirements and protocol useage differ.)

---

From: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 02:22:43 -0500

> *without any change* to the respective networks, 

except that in reality this is completely false. 

- the two networks can only "communicate" in a crippled sense
  (in that the joined network only supports a subset of the applications
  supported by either of the original networks)

- in a great many cases, the networks *do* end up being changed -
  at least in the sense that more components need to be added and
  more special configuration done just to keep the network running.
  the network also becomes more fragile.

> This is benefitial not only to provide Internet routing to

The oft-touted privacy benefits of NATs are largely an illusion.  Sometimes
you want to hide an address for the sake of privacy, sometimes you want
a stable address so that you can be reached.  The needs will differ between 
applications on a single host.  NATs hinder, rather than help, your ability 
to give each application what it needs.

> So, maybe this is what the market really wants -- a multiple-protocol 
> Internet where tools such as NAT boxes for firewalling, privacy, 
> address extension and IPv4/IPv6 interoperation will be needed ... 
> and valued.  

The market doesn't necessarily want NATs per se, but it does want some 
of the things that NATs either bring or purport to bring.  for example:

- the ability to add networks (not just hosts) at arbitrary points
  in the Internet, without getting permission from upstream to do so.
- the ability to easily renumber networks
- the ability to connect a small network to the Internet without 
  having to explicitly configure it  (plug-and-ping)
- limits to the ability to associate a source address with a particular
  user or host.

> the
> network with IPv4/NAT/IPv6. 

certainly the Internet *can* be such a network; that does not mean that
it is desirable that it be such a network.  I remember when the email 
network was a heterogeneous network consisting of UUCP, BITNET, DECnet, 
SMTP, X.400, and a few other things thrown in.  It "worked", sort of, 
but we had all kinds of problems with the translations at the boundaries,
with addresses from one network leaking past the gateways into another
network, with addresses being "translated" in such a way that they
were no longer usable in the destination network.  NATs create the same
set of problems for the whole Internet that we used to just have for
email.  Fortunately, the vast majority of email users came to their 
senses and settled on Internet protocols and the Internet email address
format.   I can only hope that NAT users will also come to their senses.

> Since a heterogeneous network can use local
> solutions for local problems, I believe Internet users will continue to 
> prefer local flexibility.

if that's really the case, they'll get rid of NATs as soon as alternative
means of solving the problems that NATs were meant to address become 
available.  our task is to come up with those alternatives.

Keith

---

From: Bill Manning <[email-masked]>
Date: Sat, 20 Jan 2001 23:30:22 -0800 (PST)

Not the best estimate but looking at the number of unique
addresses that hit&fail the public nameservers for RFC 1918 
space does show some interesting trends. A snapshot was presented
at NANOG some few meetings back.  I've got the data for the last few
years.

--bill

---

From: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 02:35:46 -0500

> routeable addresses.

no, it's the other way around.  the existence of NATs is keeping those
applications from being widely deployed.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 02:53:12 -0500

> and we have to find solutions for applications that need to deal with NAT.

By all means, let's deal with NAT.  Let's find better solutions to the
problems that NAT purports to solve - solutions that don't create the
plethora of additional problems that inherently come with NATs.   

By all means, let's stop burying our heads in the sand.  Let's stop 
pretending that we can solve these problems by further embellishing NATs,
or that the only way forward is to keep adding warts to NATs.

NAT is an architecturally bankrupt strategy - the more you try to fix 
it, the more complex the architecture becomes, the harder it becomes to 
write and configure applications, and the the more brittle the network 
becomes.  There is no way to fix the problems created by NAT without 
a global name space for points in the network topology, and this is 
the thing that NAT fundamentally destroys.
 
> denying the perceived legitimacy of NAT. 

That's not political correctness, it's sound engineering. 

Keith

---

From: [email-masked]
Date: Sun, 21 Jan 2001 14:14:51 -0500

> but we had all kinds of problems with the translations at the boundaries,

Gee thanks Keith... you bring back painful memories of running one of
the bitnet-internet gates. :)

Every few weeks, I'm *still* seeing things sniffing around for our Bitnet
gateway.  The interesting part is that the gateway (vtbit.cc.vt.edu) isn't
in the DNS anymore, hasn't been for close to 18 months, and I only *see*
these screw-ups if they manage to find the machine that *used* to be the
*unpublizised* MX front-end for the gateway.  

Let's stamp out NAT, *now* - before it becomes too entrenched and we can
never get rid of it.  We don't need that sort of "worked" again.

				Valdis Kletnieks

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 21 Jan 2001 11:19:14 -0800 (PST)

you might check out the rather sprited discussion during the plenary at
ietf49...

the official proceeding will be up shortly on the ietf website, video of
the event is at:

http://videolab.uoregon.edu/events/ietf/ietf49.html

joelja

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       [email-masked]
Academic User Services			     [email-masked]
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Jan 2001 11:32:13 -0800

>plethora of additional problems that inherently come with NATs.

The only true solution is to not use NAT. Yet it is still being heavily 
deployed.

>the thing that NAT fundamentally destroys.

I agree with that, but see no other alternative (other than waiting for 
IPv6) than improving communication through NAT piece by piece.

>That's not political correctness, it's sound engineering.

Academia and closed groups have the luxury of sticking to sound 
engineering. The rest of the world is much more complex and we have to deal 
with the ugliness of a varied topology Internet.

---

From: Daniel Senie <[email-masked]>
Date: Sun, 21 Jan 2001 14:47:32 -0500

> never get rid of it.  We don't need that sort of "worked" again.

Ummm, it's FAR too late for that. As for numbers of users, it's my guess
a large percentage of the cable modem users and DSL users are running
NAPT boxes. Given Linksys offering such appliaces at around $100, that
competes well with software-based mechanisms, and is a lot simpler for
the end user to deal with.

At the higher end, a company is offering a NAT box which permits
multi-homing without BGP. Quite useful for many large companies. In
between, there are a great many companies using firewalls with NATs.
Asking some of the ISPs for enough addresses for a company's needs for
the next 12 months gets a response of "why don't you use NAT?".

To stamp out NAT, you need to find a way to get ARIN and the ISPs to
give out appropriate quantities of IP addresses.

A better plan for those who are developing applications is to think of
ways to minimize or eliminate the impact of NAT on those applications.
While it's certainly a nice thing to SAY we'd like to be able to live in
a world without NAT and be able to develop applications which are
unencumbered by that problem, the marketplace has rolled on by and
delivered on the customers' needs.

If IPv6 had been ready 4 years ago, we might have seen a major part of
the Internet growth spurt occur on it, and the reliance on NAT be less.
Given the policies in place, and the state of the usable technology, NAT
is quite firmly ensconced. The battle you propose ("stamp out NAT") has
already been lost. This doesn't mean I'm any happier than anyone else
about the pervasiveness of NAT, just that I've accepted we have no
choice but to deliver solutions as best we can, taking NAT into account.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 20:39:00 -0500

> The only true solution is to not use NAT. Yet it is still being heavily

Understood.  But we in IETF can't do anything about what people are
deploying now.  We can however start trying to work on things 
that can get deployed two years from now.

And while it should be clear that the future of IPv4 is irrevocably
tied to NAT, the future of the Internet is not limited to IPv4.

> IPv6) than improving communication through NAT piece by piece.

The best way to improve communication through NAT is for the NAT
boxes to support IPv6 routing and 6to4.

> with the ugliness of a varied topology Internet.

I agree that the market will demand more short-term fixes. But I don't 
think we in the IETF have the luxury of abandoning sound engineering - 
at least, not if we want the Internet to continue to support diverse 
applications.  Indeed, the vendors can come up with short-term fixes 
by themselves, but it takes discussion between many different kinds
of parties, and a balance of short-term and long-term goals, 
(and hence a forum like IETF) to move things in a sane direction.

This is why I think that IETF should concentrate its energies toward
developing a viable path out of the NAT-hole rather than trying to 
dig that hole even deeper.

Keith

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Jan 2001 18:04:16 -0800

>boxes to support IPv6 routing and 6to4.

The IETF has done it's job with 6to4, but like you said we can't force 
people to deploy it. But let's stop and think about 6to4. Aren't some of 
the same "tricks" or ALG's that are planned to make applications work with 
IPv4 NAT, applicable to 6to4? If so, then we must find solutions now since 
6to4 could be with us for many years.

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Jan 2001 18:12:22 -0800

At 11:47 AM 1/21/2001, Daniel Senie wrote:
>NAPT boxes.

Speaking of DSL and NAT, I think we should give credit where credit is due 
and thank Verizon for handing out public Class A addresses to their legions 
of DSL users. If we credit them enough, three things may happen. First of 
all they will stay with this scheme and never use NAT. Secondly other DSL 
or cable providers may see the wisdom of this and do the same. Lastly 
perhaps we can reallocate some Class A address space to the large always-on 
providers who need it.

I think the Internet Society ought to give them an award or something 
(hint, hint).

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 21 Jan 2001 22:05:05 -0500

Before handing out awards: one of my colleagues here, living in
Westchester County, got a nice 10.x.x.x address (net A alright...) and
couldn't figure out why Exceed wasn't working.

However, I think it's high time to establish a "Good Housekeeping" seal
for "real" (pure, unadultared, GM-free, ...) Internet service, i.e.,

- without "transparent" caches
- no port restrictions
- no NATs

(and whatever other abominations one might want to add to this list).
Seems like a good role for ISOC, for example :-)

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Jan 2001 19:34:54 -0800

Perhaps there is a difference with the Nynex/BA side of Verizon and the GTE 
part. The GTE part uses 4.x.x.x which it got from a previous acquisition.

---

From: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 23:22:44 -0500

> the same "tricks" or ALG's that are planned to make applications work 
> with IPv4 NAT, applicable to 6to4? If so, then we must find solutions 
> now since 6to4 could be with us for many years.

Given that the whole point of 6to4 is to allow IPv6 packets to be
passed end-to-end without modification, I don't see how ALGs apply at 
all. NAT-PT of course has similar issues to v4 NAT, but NAT-PT and
6to4 are different things.

Keith

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 22 Jan 2001 10:28:36 +0000

Keith

2 ways forward are 

1/ what you propose - provide clean, alternate
complete solutions for today's ISPs - 6to4 is only part of a big
system deployment-  it would be nice to come up with smaller stageing
posts along the way....something i've wondered about:

NAT is predicated at least partly on the observation that a lot of 
internet users don't appear to need to be "always on" 
(i.e. like temporal locality
(not spatial locality) of telephone nets,
there's a distribution of use and it means that we can get away with
far less address allocated than users.....

  I would suggest that if an ISP asks for address space based on a
number of users but then uses NATs they are misrepresenting the
number of users and should be given less address space:-)
(i think this is doubly fair since they make less use of addreses, AND
less applications are able to run to and from their users)

2/ make a clear business for ISPs to offer NAT free access as a
competetive advantage....

3/ here's a silly idea - take some of the address space and make it
client only. (i.e declare half the remaining address space to be
assymetric - truth in advertising...
since there's then no servers, you can use port expanders on the low
1024 bits of the tcp or udp port to get more addresses....(yes, port
nats, but as part of the official address allocation plan...)

 cheers

   jon

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 22 Jan 2001 11:25:17 +0000 (GMT)

> far less address allocated than users.....

That's what DHCP dynamic allocation is for.

> number of users and should be given less address space:-)

and if they're using DHCP?

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Daniel Senie <[email-masked]>
Date: Mon, 22 Jan 2001 10:33:49 -0500

> http://videolab.uoregon.edu/events/ietf/ietf49.html

What can be heard on the audio (some of the question microphones were
not connected to the video capture system) showed a rather less
"spirited" discussion than I thought I'd find based on your message. I
took the opportunity to watch some of the presentations, which helped
provide context (especially Randy's presentation on DNS, and the
comments within on architectural restraint).

The "spirited discussion" consisted of a limited number of people saying
things that either they or others have said before. Perry, for example,
talked about the costs of multiple, overlapping NAT stuffs and the huge
amounts of money that's costing folks. He's made the same point in other
plenaries and in other meetings. What he said is certainly a problem,
and one we'd all like to see disappear. Keith expressed concern
(starting the discussion) that the IETF should be working on a better
architecture to deal with replacing NAT. To do so, we'd have to solve
the customer needs which are driving folks to NAT, of course.

So, in reviewing the video, I saw people generating plenty of heat, but
little light.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Jan 2001 09:54:47 -0600

> 6to4 are different things.

Indeed. 6to4 is a solution for IPv6 islands to talk to other IPv6 islands.
No ALG issues at all. (The "to" represents the address mapping trick used.)

NAT-PT solves a different problem - how can IPv6-only devices communicate
with the IPv4 legacy? And that does call for ALG support.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Jan 2001 09:59:22 -0600

Henning Schulzrinne wrote:
...
> - without "transparent" caches

Do you mean interception proxies, in WREC terminology? 

> - no port restrictions

And no protocol type restrictions

> - no NATs

How about adding IPv6 support?
> Seems like a good role for ISOC, for example :-)

The ISOC isn't a trade association, which is where such seals
of approval (and the associated b*ke-offs) tend to come from.

    Brian

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 22 Jan 2001 11:53:08 -0500

Brian E Carpenter wrote:

> Do you mean interception proxies, in WREC terminology?

Yes.

> How about adding IPv6 support?

Good idea.

> of approval (and the associated b*ke-offs) tend to come from.

Maybe the IPv6 consortium or whatever they call themselves could do
this, since IPv6 is a (the only?) realistic alternative to NATs.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: John Stracke <[email-masked]>
Date: Mon, 22 Jan 2001 12:42:56 -0500

Keith Moore wrote:

> I remember when the email
> were no longer usable in the destination network.

There was even an analogy to NAT's "addresses embedded in the application data
stream" problem: if you had an address in your .signature, the gateway couldn't
translate it, so the person receiving your message saw an address they couldn't
use.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Go not to the Vorlons for advice, for they will|
[email-masked]|say both no and sherbert.                      |
\================================================================/

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 22 Jan 2001 12:34:50 -0800

>this, since IPv6 is a (the only?) realistic alternative to NATs.

Long term, yes. But Class A addresses for all the always-on users today 
would eliminate a heck of a lot of NAT out there. And I wasn't referring to 
a "seal-of-approval". Just some sort of formal recognition.

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Jan 2001 16:52:06 -0500

> There was even an analogy to NAT's "addresses embedded in the application 
> data stream" problem: if you had an address in your .signature, the gateway
> couldn't translate it, so the person receiving your message saw an address 
> they couldn't use.

at least in those days, gateway proponents didn't insist that people
shouldn't include email addresses in the bodies of their messages.

Keith

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 23 Jan 2001 01:11:12 +0100

>translate it, so the person receiving your message saw an address they 

I liked even better the horror story of the gateway that tried.....
until someone wrote "this gateway translates [email-masked] into 
[email-masked]", and it came out to the recipient as
"this gateway translates [email-masked] into 
[email-masked]".....which somehow failed to get the point 
across....

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: [email-masked]
Date: Mon, 22 Jan 2001 22:49:17 -0500

> [email-masked]".....which somehow failed to get the point 

The best one-paragraph summary of RFC2993 I've seen yet.

/V

---

From: [email-masked]
Date: Tue, 23 Jan 2001 18:28:12 -0800 (PST)

> [email-masked]".....which somehow failed to get the point

I've actually seen this happen. Mail system configuration files sent to us from
behind such a gateway were curiously corrupt when they reached us, and when we
fixed them and sent them back the errors were in what was received... Turned
out that someone took the corporate mandate to "remove all references to our
old name" a bit too seriously.

If memory serves, we used ROT13 to get around the translation, since
administrative turfs were such that an actual fix for the problem wasn't
possible.

				Ned