Subject: Stupid NAT tricks and how to stop them.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 08:41:15 -0800

> From: Henning Schulzrinne [mailto:[email-masked]] 

> Trying to devise ever more elaborate NAT traversal mechanisms 
> that include sending keep-alives every few seconds and 
> various "let's try this and then that" algorithms clearly 
> don't scale if we want to get to consumer-grade reliability, 
> not just interesting toys that try to stay one step ahead of 
> the next stupid NAT trick.

The reason for all those 'stupid NAT tricks' is precisely the attitude you
show here

FACT: IPv4 address space is a scarce resource only viable because of NAT.

FACT: People do not want to pay their cable ISP for extra connections.

FACT: Smug exhortations to move to IPv6 ignore the fact that there is no
transition plan.

The obvious way to deploy IPv6 is to leverage the NAT infrastructure. Devise
a protocol suite that allows a NAT box to transparently support IPv4 or IPv6
on either side of the box. Evangelize to the major providers of NAT (Cisco,
Netgear, Microsoft, Belkin...). 

What I would like to come out of the IAB is a stream of documents that 1)
identify pain points that are being felt in the current Internet
architecture, 2) hold solutions workshops leading to architecture documents
that identify proposed solutions together with fair summaries of counter
proposals.

The IRTF was apparently intended to fill this role, given the pace of
Internet development an organization that works even slower than the IETF is
not capable of providing useful input on addressing a pain point.

The IETF has not had a voice in the major issues that the Internet has been
facing. On spam the IETF voice was hijacked. On Internet crime the IETF is
silent.

> Thus, I think we need a separate organization (or work with a separate
> organization) that does branding and certification. It's hard 
> to buy a non-WiFi device in stores today; the equivalent 
> consumer assurance needs to be true for core consumer and 
> small-business network devices, and possibly services.

That is a good idea, but the systems design MUST meet the real needs of
actual customers. The problem with large amounts of IETF design is that
abstract engineering fetish is put ahead of meeting real users needs. 

For such a forum to be viable it would require the active participation of
the application providers. For that to happen the specs would have to result
in a sellable product which means meeting real customer requirements.

Paul Hoffman has in fact created something of the sort, it does not have the
level of consumer recognition that is required and the level of
participation is less than is needed but it could potentially be built on. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Dave Aronson (re IETF)" <[email-masked]>
Date: Mon, 27 Mar 2006 19:20:37 +0000

> > > the NAT vendors are just eating their seed corn.
 > > 
 > > Your long term view is irrelevant if you are unable to meet short term
 > > challenges.
 > 
 > very true.   but at the same time, it's not enough to meet short term
 > challenges without providing a path to something that is sustainable in
 > the long term.

Tastes great!

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 12:02:11 -0800

OK, it is an intersubjective truth accepted throughout the IETF that a
decade is far to long for deployment of DNSSEC.

It is an empirical fact that this is four years longer than it need have
been. Deployment would have taken place in the .com zone 2002 if the
necessary changes to the specification had been allowed. 

> -----Original Message-----
> From: Scott Leibrand [mailto:[email-masked]] 
> Sent: Monday, March 27, 2006 2:50 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]; [email-masked]
> Subject: RE: Stupid NAT tricks and how to stop them.
> 
> On 03/27/06 at 11:38am -0800, Hallam-Baker, Phillip 
> <[email-masked]> wrote:
> >
> > People can dispute opinions but not facts. The fact is that it has 
> > taken far too long to deploy DNSSEC.
> 
> Just a nit, as I can't really disagree with your assertion 
> (nor can I necessarily agree with it, as I haven't been 
> involved with DNSSEC), but:
> 
> The words "too long" flag your statement as an opinion, not a 
> fact.  The fact that you assert a statement is a fact doesn't 
> necessarily make it so.
> 
> -Scott
>

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 28 Mar 2006 09:16:18 -0500 (EST)

> From: Scott Leibrand <[email-masked]>

    > NAT (plus CIDR) was the short-term solution,

Do note that CIDR was intended as a solution to a number of problems, not
just consumption of address space - like this one:

    > From: "Michel Py" <[email-masked]>

    > Especially now that the size of the routing table is not a problem
    > anymore.
    > ...
    > Also came memory issues with the global routing table. Some, including
    > me, said it was un-maintainable and would result in the Internet
    > collapsing. 

Since this old canard has resurfaced again, it's clearly time to drag out
some old messages, which I resend every couple of years, and send them
around yet again.

The executive summary is: The issue with routing table size (and why big
ones are Very Bad) is really not the size of the memory needed to hold the
table (which is a static thing), but the dynamics - i.e. things like
stabilization time after topology changes (and we have real problems there,
as all the fancy BGP route-flapping and dampening stuff attests).

For more, check out:

  Date: Sat, 9 Sep 95 17:22:17 -0400
  From: [email-masked] (Noel Chiappa)
  Message-Id: <[email-masked]>
  To: [email-masked], [email-masked]
  Subject: Routing "experts"

[Apologies for the rather cranky/snide tone in this one - I was pretty
stressed out at the time.]

  Date: Thu, 22 Feb 96 12:44:33 -0500
  From: [email-masked] (Noel Chiappa)
  Message-Id: <[email-masked]>
  To: [email-masked]
  Subject: Re: Last Call: Implications of Various Address Allocation Policies for Internet Routing to BCP
  Cc: [email-masked], [email-masked], [email-masked]

  Date: Thu, 22 Feb 96 12:44:33 -0500
  From: [email-masked] (Noel Chiappa)
  Message-Id: <[email-masked]>
  To: [email-masked]
  Subject: Re: Last Call: Implications of Various Address Allocation Policies for Internet Routing to BCP
  Cc: [email-masked], [email-masked], [email-masked]

Someday I'll get energetic and turn these into a web page on the subject
(like my 'Will The Real "End-End Principle" Please Stand Up?' page). Alas,
no time at the moment.

No doubt some people, looking at the dates on these, will say "see, we've
gone ten years without running into the problems you mention, therefore they
don't exist". I must admit, I'm fairly amazed we haven't seen worse problems
with the routing because of table size. I can only attribute our lack of
observed problems to some very careful engineering by the ISP's.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 28 Mar 2006 10:06:17 -0500 (EST)

>> Tim Chown wrote:
    >> If you deploy IPv6 NAT, you may as well stay with IPv4.

    > You're the one who convinced me some three years ago that there will
    > be IPv6 NAT no matter what, what's the message here?

I think Tim's point is that the only realistic options are:

i) IPv4+NAT
ii) IPv6 without NAT.

The IPv6+NAT option makes little (no?) economic/technical sense - it has all
the operational downsides of IPv4+NAT, plus to which you have the cost/hassle
of deploying v6.

    > and possibly allocate PI to everybody which is another pre-requisite
    > to get rid of NAT.

We aren't *ever* going to give everyone PI space (at least, PI space in
whatever namespace the routers use to forward packets), any more than we are
going to let them take their street addresses with them when they move.

Routing (i.e. path-finding) algorithms simply cannot cope with tracking 10^9
individual destinations (see prior message).

	Noel

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 28 Mar 2006 10:48:48 -0500

Noel,

	I think the "street address" analogy is not close
enough - anymore than longitude and latitude numbers or
any other description of physical location.

	The problem with physical location portability is
that the location remains even if you're not in it.  So
someone else might need to describe their own physical 
location using the same description.

	Number assignments, however are substantially more
portable.

	It is certainly possible for an IPv6 address pool
manager to allocate personalized IPv6 addresses from an
IPv6 address pool that they manage and thereby assume
responsibility for end-delivery (by any means possible)
- thus providing for indefinite address portability.
In this sense, this is more analogous to phone number
portability or tax identifiers.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> Sent: Tuesday, March 28, 2006 10:06 AM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: RE: Stupid NAT tricks and how to stop them.
--> 
-->     > From: "Michel Py" <[email-masked]>
--> 
-->     >> Tim Chown wrote:
-->     >> If you deploy IPv6 NAT, you may as well stay with IPv4.
--> 
-->     > You're the one who convinced me some three years ago 
--> that there will
-->     > be IPv6 NAT no matter what, what's the message here?
--> 
--> I think Tim's point is that the only realistic options are:
--> 
--> i) IPv4+NAT
--> ii) IPv6 without NAT.
--> 
--> The IPv6+NAT option makes little (no?) economic/technical 
--> sense - it has all
--> the operational downsides of IPv4+NAT, plus to which you 
--> have the cost/hassle
--> of deploying v6.
--> 
--> 
-->     > and possibly allocate PI to everybody which is 
--> another pre-requisite
-->     > to get rid of NAT.
--> 
--> We aren't *ever* going to give everyone PI space (at least, 
--> PI space in
--> whatever namespace the routers use to forward packets), any 
--> more than we are
--> going to let them take their street addresses with them 
--> when they move.
--> 
--> Routing (i.e. path-finding) algorithms simply cannot cope 
--> with tracking 10^9
--> individual destinations (see prior message).
--> 
--> 	Noel
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Mar 2006 12:55:23 -0500

If we are willing to accept arbitrarily long paths to get from point 
A to point B, there are techniques which allow topologically 
insensitive packet handling.  The Home-Register (aka HLR lookup) is 
one way.  (The routing reserachers have described this topic as 
"stretch > 1" routing.  There are many non-deployable ideas 
there.  If we really didn't care about path distortion at all, I am 
sure something deployable could be crafted.)
Note however that local number portability is actually a bad 
analogy.  The phone system internally does not work on phone numbers 
any more (it once did).  Your phone number is really more akin to an 
identity.  Phone you call someone, the system does a name lookup (ala 
DNS) and then gets a routable location.

Yours,
Joel

At 10:48 AM 3/28/2006, Gray, Eric wrote:
>To: [email-masked], [email-masked]

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 28 Mar 2006 13:45:14 -0500

Noel,

	Delivering IP packets _always_ involves a translation
service.  Usually, more than one, but - assuming we start
with IP addresses - there is at least one MAC (or other L2)
lookup that must occur before the packets can be delivered.

	We should be careful not to assert "layer dependent"
statements in a world in which layering is only locally
unambiguous.

	The problem with the "road-network" analog is that I
have no "intrinsic" requirement to relinquish "my" network 
address because I've become mobile.  The same thing could -
in theory - be said about street addresses, but the current
binding/interpretation of street addresses is entrenched in
centuries of usage that prevents this from (probably) ever 
becoming practical.

	That is not only NOT true in theory for IP(v4/v6) 
addresses, it is not true in practice.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> Sent: Tuesday, March 28, 2006 1:17 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: RE: Stupid NAT tricks and how to stop them.
--> 
-->     > From: "Gray, Eric" <[email-masked]>
--> 
-->     > I think the "street address" analogy is not close 
--> enough - anymore
-->     > than longitude and latitude numbers or any other 
--> description of
-->     > physical location.
--> 
--> No, it's a very good analogy, because the road network is a 
--> very good analog
--> to the data network. To see how, let's do a though-experiment.
--> 
--> Embed the road-network, not on the surface of a solid 
--> sphere, but on the
--> surface of a flexible hollow spherical surface. Now, 
--> distort that surface
--> arbitrarily. The location (in spatial coordinates) of any 
--> place on that road
--> network has changed totally - but the set of directions 
--> you'd use to get
--> from one point in the road network to another ("go down 
--> road A until you
--> meet the junction with B, and turn onto B in the direction 
--> of C", etc, etc)
--> remains unchanged.
--> 
--> What is most important about both the data network, and the 
--> road network, is
--> the *connectivity pattern* - what connects to what. That's 
--> because packets
--> are (usually) constrained to travel down links, and 
--> vehicles are (usually)
--> constrained to travel down roads.
--> 
-->     > The problem with physical location portability is 
--> that the location
-->     > remains even if you're not in it.
--> 
--> But the exact same thing is true of a network - Port #0 on 
--> ISP A's router R
--> is the same place in the network (i.e. you use the same 
--> directions to get to
--> it - see above) whether company X or company Y is plugged 
--> in there - just as
--> 126 Main Street is the same building, whether company X or 
--> company Y is
--> housed there.
--> 
-->     > Number assignments, however are substantially more portable.
--> 
--> Saying that doesn't make it so. You can easily (sic) change 
--> street names
--> too, to make a street name "portable".
--> 
--> 
-->     > It is certainly possible for an IPv6 address pool 
--> manager to allocate
-->     > personalized IPv6 addresses from an IPv6 address pool 
--> that they manage
-->     > and thereby assume responsibility for end-delivery
--> 
--> That's just a translation service from *virtual* addresses 
--> to real ones -
--> those IPv6 "addresses" aren't the names of locations in the 
--> network: if the
--> pool manager *actually wants to get packets* to those 
--> entities, it is going
--> to have to translate those "addresses" into the real 
--> addresses at which
--> those entities can be found.
--> 
--> 	Noel
-->

---

From: "Michel Py" <[email-masked]>
Date: Fri, 31 Mar 2006 09:34:47 -0800

Christian,

What you wrote is doubly incorrect.
First, you missed the context:

>> Noel Chiappa wrote:
>> Needless to say, the real-time taken for this process to complete
>> - i.e. for routes to a particular destination to stabilize, after a
>> topology change which affects some subset of them - is dominated by
>> the speed-of-light transmission delays across the Internet fabric.
>> You can make the speed of your processors infinite and it won't make
>> much of a difference.

> Christian Huitema wrote:
> Since events imply some overhead in processing, message passing,
> etc, one can assume that at any given point in time there is a
> limit to what a router can swallow.

This is true indeed, but a) this limit has everything to do with
processing power and available bandwidth and nothing to do with speed of
light and b) the context was talking about infinite processing power
anyway.

> Bottom line, you can only increase the number of routes
> if you are ready to dampen more aggressively.

There is no close relation. Dampening affects route that flap. If the
new routes don't flap, all that is required is more memory to hold them
and slightly more CPU to perform lookups but not much more as the
relation between lookup time and size is logarithmic. Read below for
handling routes that flap because they indeed do.

> There is an obvious "tragedy of the commons" here: if more network
> want to "multi-home" and be declared in the core, then more aggressive
> dampening will be required, and each of the "multi-homed" networks
will
> suffer from less precise routing, longer time to correct outages, etc.

Again I don't see a relation here. Assuming that the newer prefixes in
the core flap about as much as the current ones, what is required to
handle more is to increase computing power and bandwidth in order to
keep what a router can swallow under the limit it takes a hike.

> There are different elements at play that also limit the number of
> core routers. Basically, an event in a core router affects all the
> path that go through it, which depending on the structure of the graph
> is somewhere between O(M*log(M)) or O(M.log(M)). In short, the routing
> load grows much faster than linearly with the number of core routers.

I agree; the relation between processing power requirements and number
of prefixes is somehow exponential, but back to the real world:

Years there was a frantic forklift upgrade business to get the biggest
baddest BFR from vendors even before the paint was dry, and this
happened because indeed we were starving for more CPU and more memory.

This does not happen today. As Stephen points out, even the little guys
aren't complaining anymore and vendors don't even put the latest
technology they can in their products because nobody's screaming for it
anymore.

In short: the IPv6 idea of reducing the size of the routing table was
necessary if IPv6 had been deployed and replaced v4 5 years ago. We have
missed the launch window and as of today this problem solved by time; I
hear that we could handle a million prefixes with today's technology.

If it takes a THz processor to handle 10 million prefixes and a 100THz
one to handle 100 million prefixes, I don't care as long as said
processors are on the shelf at Fry's for $200 a piece and on a vendor's
Sup for $100K a piece.

Michel.