Subject: [lisp] LISP-NAT - explanation and support?

From: Robin Whittle <[email-masked]>
Date: Tue, 22 Sep 2009 14:53:18 +1000

Short version:   Can anyone explain exactly how LISP-NAT is
                 supposed to work, what it is useful for (especially
                 in terms of what it can do which other approaches
                 can't) and what its limitations are?

                 Does anyone argue that LISP-NAT will actually
                 be useful enough to be adopted?

                 If there isn't sufficient support for LISP-NAT
                 I would welcome at least a tentative consensus that
                 it be relegated to some kind of historic status,
                 unless it someone significantly revises it.  This
                 would avoid LISP-NAT turning up in future
                 discussions as if it was practical and desirable
                 when (I think) most people believe it is not.

I have never been able to understand how LISP NAT would work, and
have written critiques of it in the past.

Noel wrote:

 http://www.ietf.org/mail-archive/web/lisp/current/msg01550.html

> . . . it is of course always better to avoid NAT if you can;
> because NAT mangles packets (which breaks some things, including
> some kinds of IPSec, for instance), and won't always work (e.g.
> for protocols which won't work through NATs, e.g. if they have
> embedded addresses, etc).
>
> So LISP-NAT is not actually a 100% replacement for a PETR if you're
> on a uRPF ISP.

In the next message, Joel wrote:

> So, unless there is a deployment model in which PITR and PETR
> deployments make economic sense, LISP will be dependent upon
> LISP-NAT. I for one do not consider NAT a solution worth offering
> the world.

So that's three people who are critical of LISP-NAT.

Darrel wrote (msg1545):

> Well, I personally prefer both Proxy ITRs and Proxy ETRs to NAT,
> but your mileage may vary! :-)

but in the previous message:

> If I could not get a PETR service 'close enough', I would use
> LISP-NAT for this (URPF avoidance) purpose.  As Dave pointed out
> in his email, a very interesting (to me) side effect of both
> Proxy ITRs and Proxy ETRs are that LISP sites see the benefits
> (ingress TE and protocol independent data plane) of LISP day one.
> Both I consider optional however, since LISP-NAT is an alternative.

Are there any good explanations, with examples, of how LISP-NAT would
work and be useful enough to be deployed and adopted?

   - Robin

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 25 Sep 2009 12:15:38 -0700

Robin,

>                  be useful enough to be adopted?

The LISP Interworking draft explains how LISP-NAT works, and why it is
useful.  LISP-NAT can be used in conjunction with Proxy Ingress Tunnel
Routers, or on its own to enable hosts at a LISP site to exchange
packets with hosts at a non-LISP site.  Sites using LISP-NAT can on
their own decide their hosts from Non-Routable) EID space, while
communicating with non-LISP sites via its outside Routable (LISP-R)
EIDs.  Thus it can be an alternative to using network based Interworking
infrastructure.

For an interesting discussion of the limitations of NAT in general, you
might read:
http://tools.ietf.org/id/draft-vogt-address-translation-harmfulness-03.t
xt which seems to cover most of the caveats of using NAT.

You mentioned in an earlier email that you doubted whether LISP-NAT can
be made to actually work, but we have existence proof in the existing
LISP network that it can be implemented successfully.  I also don't want
to be drawn into a debate about the pro's and cons of NAT, except to say
that it exists, and is popular for IPv4.  Since NAT exists, and can be
applied to solve the Interworking problem,  the authors decided to
include it in the Interworking specification and to experiment with it.

-Darrel

---

From: Robin Whittle <[email-masked]>
Date: Sat, 26 Sep 2009 18:37:00 +1000

Hi Darrel,

You wrote:

> useful.  

The current draft (2009-05-26):

  http://tools.ietf.org/html/draft-ietf-lisp-interworking-00

is the same as (2009-01-27):

  http://tools.ietf.org/html/draft-lewis-lisp-interworking-02

which is the same as (2008-07-10):

  http://tools.ietf.org/html/draft-lewis-lisp-interworking-01

Regarding LISP-NAT, all the above are only substantially different
from the original version:

  http://tools.ietf.org/html/draft-lewis-lisp-interworking-00
  2007-12-05

due to the addition of para 6.5. which remains the same today
(including a typo "hbe").

To my understanding PTRs are both necessary and sufficient to solve
the problem of getting packets addressed to EID addresses sent by
hosts in networks which lack ITRs ("non-LISP sites") to the ETR of
the destination network.  Without this, no-one would want to adopt
LISP-mapped EID address space.

What does LISP-NAT add to PTRs in any realistic widespread adoption
scenario?

There is nothing in 6.5 which helps me understand why anyone would
want to use LISP-NAT when there are PTRs covering their EID address
space.

Since the purpose of LISP is to reduce the number of routes in the
DFZ, I assume that when LISP is introduced, all EIDs will be
encompassed by a DFZ route advertised by one, or ideally many, widely
distributed, PTRs.  This single route covers the EID requirements of
many LISP-using end-user networks, so the key goal of scalable
routing is achieved.

Does LISP-NAT have any role in a real world-wide adoption of LISP?

Is there any explanation of how this would work, with examples?

> LISP-NAT can be used in conjunction with Proxy Ingress Tunnel

I don't see why anyone would want to adopt LISP on this basis.

> include it in the Interworking specification and to experiment with it.

OK - do you expect LISP to be voluntarily adopted by anyone if their
EID space is not supported by PTRs?

If so, how would such adoption help with scalable routing? "scalable"
doesn't appear in these I-Ds.

I first wrote a critique of LISP-NAT in December 2007:

  http://psg.com/lists/rrg/2007/msg00674.html

As I wrote then, as far as I know:

  LISP-NAT provides no multihoming, portability etc. benefits, for
  the packets coming from the host in the site with no ITR - while
  PTRs provide all these the benefits.

How can LISP-NAT enable a host in a non-LISP network to send packets
to a host using an EID address, unless the communication is initiated
by the host with the EID address?

 - Robin