Subject: RE: PAT

From: [email-masked]
Date: Wed, 16 Aug 2000 08:56:18 -0500

It is what cisco calls IP overloading.  It is where multiple off-net
addresses share a single public IP.  The router keeps track of the full
socket in order to remember which off-net address gets which incoming
packets.  Cisco refers to NAT as having a one-to-one relationship between
off-net and public IPs, so that every host with a private address has a
corresponding public address in the router's NAT table.  This uses more
public IPs, but makes the NAT process faster since it doesn't have to read
as far into the packet as PAT does.  It also allows for an off-net host to
more easily service a wide array of ports.  A Cisco router will do either
PAT or NAT.

Keith Moore will tell you that you shouldn't bother with either PAT or NAT
because they both violate the end-to-end connectivity convention of the
Internet, and they break a long list of standard protocols (he will send you
the RFC that lists several), and have been an evil band-aid on the IPv4
address scarcity problem and have hindered progress by prolonging the use of
v4 and forestalled mass IPv6 implementation.  Did I miss anything, Keith?
:-)

Brian

-----Original Message-----
From: Peter Burggasser [mailto:[email-masked]]
Sent: Tuesday, August 15, 2000 1:34 PM
To: Mailinglist
Subject: PAT

hy

could anyone tell me whats PAT on cisco router is ? its in conjunction
with ip domain-lookup on the router, but i didnt find anything about.

thanks for help

cu peter

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Aug 2000 11:18:50 -0400

> v4 and forestalled mass IPv6 implementation.  Did I miss anything, Keith?

yes.

you should use NAT or NAPT only if you really understand the consequences
of doing so, both on current and future applications.  (Hint: if you think 
that they only break apps that send addresses over the wire, you don't 
understand the consequences.)  there are situations where NAT or NAPT
are harmless, but they are rare.

(note: I prefer the term NAPT to PAT, but I think they are equivalent.)

the impact of NAT on nonstandard application protocols is greater than 
the impact of NAT on standard protocols; this is largely because NATs
typically contain ALGs to work around their inability to support popular
protocols.  but the Internet exists to support many different kinds of
protocols - not just the (currently) standard ones, and it's very 
important that the Internet be able to support new kinds of applications.

my list isn't one of standard protocols that NATs break, but one of 
common and reasonable application assumptions that NATs break.
I wrote the list because people kept making incorrect assertions about
NATs.  you can use it to better understand the limitations of NAT.  you 
can also use it to write applications that are more compatible with NAT.  
see http://www.cs.utk.edu/~moore/what-nats-break.html

I don't know that NATs have hindered progress of IPv6 nearly as much
as they've hindered progress of certain kinds of applications.
NATs have delayed the exhaustion of IPv4 space, but people differ on
whether this is a good or bad thing.  My feeling is that we would
have needed NATs to some degree by now anyway, but that they are being
widely misrepresented and inappropriately used in many (most?) instances.

I'm not nearly so opposed to the well-informed, voluntary, intelligent 
use of NATs as I am to the misrepresentation of NATs.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2000 13:58:52 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> I don't know that NATs have hindered progress of IPv6 nearly as
    Keith> much as they've hindered progress of certain kinds of
    Keith> applications.  NATs have delayed the exhaustion of IPv4 space, but

  I must agree with the accessment.

  To get rid of them, we need to be able to get IPv6 address space for
essentially zero cost. As long as address space is scarce, people will
attempt to conserve it by using NAPTs. 

  Note, I make a distinction between routable address space (which may be
scarce due to size of routing tables) and address space. If I had available
address space for my internal networks that never (what I think now) need to
talk to the Internet, then I'd use it. If I had to connect things to the
Internet, etc. then there would be no problem.

  So, my opinion is that the bottleneck for deploying IPv6, and therefore
getting rid of NAPTs is the cost of IPv6 address space.

  ... 3ffe:1ce1:0:fe50::29	(alas, from experimental space)

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Aug 2000 15:00:59 -0400

> getting rid of NAPTs is the cost of IPv6 address space.

it's one of the potential bottlenecks.  certainly not the only one,
probably not the largest.  folks still have to learn about the
differences between IPv4 and IPv6, and applications using IPv6
have to be deployed. those are significant bottlenecks.

note that 6to4 makes the cost of getting a good-sized chunk of IPv6 
address space roughly equivalent to the cost of getting a single stable 
IPv4 address.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2000 15:57:29 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> it's one of the potential bottlenecks.  certainly not the only
    Keith> one, probably not the largest.  folks still have to learn about
    Keith> the differences between IPv4 and IPv6, and applications using IPv6
    Keith> have to be deployed. those are significant bottlenecks.

  KAME is doing this at such a high rate, that I expect to be able to run
IPv6 only on my desktops at my two offices by the end of the year. I know
that Perry is pretty close if not already there on this one.
  Combined with a web proxy and/or 6to4 for external access and I'm set.

    Keith> note that 6to4 makes the cost of getting a good-sized chunk of
    Keith> IPv6 address space roughly equivalent to the cost of getting a
    Keith> single stable IPv4 address.

  But, where do I get that chunk of IPv6 address space?

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 16 Aug 2000 14:12:19 -0700

>   But, where do I get that chunk of IPv6 address space?

From your service provider, of course.

If you (as an end user, presumably -- apologies if this is not a correct
assumption) do not get your address space from your service provider,
you will be creating the exact same swamp problem that exists with
IPv4.  Only the potential size of the swamp is many orders of magnitude
larger.

Rgds,
-drc

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2000 18:47:55 -0400

>>>>> "David" == David R Conrad <[email-masked]> writes:
    >> But, where do I get that chunk of IPv6 address space?  From your
    >> service provider, of course.

    David> If you (as an end user, presumably -- apologies if this is not a
    David> correct assumption) do not get your address space from your
    David> service provider, you will be creating the exact same swamp
    David> problem that exists with IPv4.  Only the potential size of the
    David> swamp is many orders of magnitude larger.

  This is a red-herring. 
  
  a) my service provider isn't IPv6 ready. I am doubtful that any of them
	will be for a long time as far as I can tell. I will be building a
	tunnels for a long time. 
	(traceroute to wirespeed.solidum.com if you want to know who my ISP is)

  b) in the situation where I am using IPv6 instead of RFC1597, then
	my address can't be topologically significant.

  c) multihoming.

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 16 Aug 2000 16:38:55 -0700

Hi,

>   This is a red-herring.

Actually, it's not.  People are complaining that it is hard to get v6
addresses from the regional registries when (a) it is in fact easy (many
argue too easy) and (b) in fact they shouldn't be getting them from the
registries in the first place since v6 uses provider based addressing. 
Only transit providers (whatever they are) should be getting v6
addresses from the registries.  Everyone else should be getting their
addresses from their (IPv6) upstream provider.  If an (IPv6) upstream
provider does not exist, then any set of numbers will do as the site
will have to renumber when it does get an (IPv6) upstream provider.
 
>   a) my service provider isn't IPv6 ready. 

Just curious (honestly), but have you indicated to them that you'd
really like them to be v6 ready?

> I am doubtful that any of them

Then you should get the address space from your tunnel provider.

>         my address can't be topologically significant.

If you're using this in the context of private networks, then any set of
numbers would do.  Why not pick one at random?

>   c) multihoming.

If you are multihoming then you should get addresses from each of your
(tunnel) providers.  Unless, of course, you are doing this in the
context of 1918 private networks, in which case it doesn't matter what
addresses you use.

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Aug 2000 08:37:19 -0500

"David R. Conrad" wrote:
...
> numbers would do.  Why not pick one at random?

er, no. In this case you should use IPv6 site-local addresses.

Please, please, nobody ever pick a prefix at random. Your prefix should *always*
come from your upstream provider, up to the level of Top Level Aggregator,
which comes from a registry.

  Brian

---

From: Sean Doran <[email-masked]>
Date: 21 Aug 2000 02:30:54 +0200

"David R. Conrad" <[email-masked]> writes:

> addresses from the registries.

Since deployment seems to be based initially upon virtual
topologies that are disjoint from the underlying IPv4
topology (i.e., using tunnels), surely anyone who is open
to allowing other sites to connect to their virtual
topology should be eligible for address space?

        Sean.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Aug 2000 10:36:44 -0500

> topology should be eligible for address space?

Yes, but that doesn't *necessarily* mean a prefix short enough
to be in the (hopefully small) default free table. If someone
is setting up a regional virtual topology they begin to look
like a metro exchange and something longer than a /29 TLA
prefix might be OK. But I tend to agree with Sean.

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Aug 2000 18:18:17 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Sean Doran wrote:
    >> > Only transit providers (whatever they are) should be getting v6 >
    >> Since deployment seems to be based initially upon virtual topologies
    >> that are disjoint from the underlying IPv4 topology (i.e., using
    >> tunnels), surely anyone who is open to allowing other sites to connect
    >> to their virtual topology should be eligible for address space?

    Brian> Yes, but that doesn't *necessarily* mean a prefix short enough to
    Brian> be in the (hopefully small) default free table. If someone is
    Brian> setting up a regional virtual topology they begin to look like a
    Brian> metro exchange and something longer than a /29 TLA prefix might be
    Brian> OK. But I tend to agree with Sean.

  Bingo. That's what we (a group of interested parties, not Solidum) are
looking to setup among five friendly small/medium sized ISPs that happen to
share co-location space.