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

[Robin Whittle <rw at firstpr.com.au>]

Hi Darrel,

You wrote:

>> 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?
> 
> The LISP Interworking draft explains how LISP-NAT works, and why it is
> 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
> 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.

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


> 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.

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