Subject: [lisp] draft-klein-lisp-mn-nat-traversal-00 and TTR Mobility

From: Robin Whittle <[email-masked]>
Date: Wed, 14 Jul 2010 02:05:20 +1000

Hi Dominik, Matthias, Michael and other LISP folk,

The new I-D:

  http://tools.ietf.org/html/draft-klein-lisp-mn-nat-traversal-00

seems to result in two separate tunnels, with the data directions
shown with arrows.  Both are established by the MN, and the destinations:

  NTR   Nat Traversal Router
  PETR  Proxy ETR

while architecturally different and developed at different times by
different people, are both (typically, at least) intended to be
co-located with the MS:

            ITR ->-\
                    \
            ITR -->---NTR--->-----\
                    /  .           \
            ITR ->-/   .            \
                       .             MN
                       .            /
   Non-EID     }       .           /
   destination } --<--PETR--<-----/
   hosts       }

These PETR arrangements are described in:

  http://tools.ietf.org/html/draft-meyer-lisp-mn-01#section-7.2

The rest of section 7 concerns packets leaving the MN, addressed to
EID-addresses, in various circumstances.  I haven't tried to
understand these variations.  However, none of them will work for a
MN behind NAT, because the outgoing packets have EID source
addresses, and we can't be 100% sure the network behind the NAT, or
the NAT box itself, will let them out.  It is reasonable to assume
the contrary - that such packets would be dropped.

So I think all the outgoing packets need to go to what you currently
think of as the PETR.  Then, some will be forwarded to non-EID
destinations and the rest will be handled by an ITR function in the
same device, or perhaps nearby.

The concept of a MN tunneling to another router, in part so it can
work behind one or more levels of NAT, was first described as part of
my original TTR (Translating Tunnel Router) Mobility description in
June 2007, towards the end:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

The MN establishes the tunnel to the TTR,  It is a 2-way tunnel,
which can be encrypted and have its own Path MTU Discovery
arrangements, since it is just between the MN and the TTR, both of
which are part of the Ivip or whatever architecture.

In addition, the MN can be on an address which itself is provided
with this mobility mechanism.  In principle, any number of recursions
of NAT and this form of mobility can be used, in any order.  In all
cases, the MN can tunnel to anywhere in the Internet, including to
any of the TTRs.

TTRs are all around the Net, as commercial services from one of
multiple TTR Mobility companies.  The MN pays for services from one
of these companies, and the MN has special tunneling software to
connect to nearby TTRs of that company.

That company need have no relationship with any ISP the MN is using,
or with whoever the MN obtains their EID (LISP) space from.  However,
the MN user does need to give control of the mapping of their one or
more EID prefixes to the TTR company.  I think it is a bad idea
having a MN trying to control the mapping of its own EID prefixes.

The TTR acts as an ETR for this and multiple other MNs.  The MN
establishes the tunnel to the TTR, and it is used for two-way data
exchange to and from the TTR, as well as for management traffic for
the special tunneling software in the MN.

Apart from this software, the MN is an ordinary host.  It can use any
access network.  The TTR system is separate from access networks and
there is no need for any MIP systems - though the MN could be using
MIP.  TTR Mobility will work for IPv4 and IPv6 - with correspondent
hosts being unmodified hosts, or any other hosts using Ivip (or
whatever other Core-Edge Separation architecture, since TTR Mobility
could be adapted to LISP too).

The MN gets to keep its EID space wherever it goes, and as long as it
uses a generally nearby TTR, there will be little path stretch.
There is no fixed "home agent".  The EID space is just like any other
LISP EID prefix.

The TTR handles outgoing packets - either forwarding them directly to
their destination hosts or performing an ITR operation on them so
they are tunneled to the correct ETR.  (The TTR could just emit them
and let them be forwarded to the nearest Ivip DITR or LISP PTR, but I
generally assume that each TTR has an inbuilt, or nearby, ITR.)

The main benefits of TTR Mobility are:

  1 - As with lisp-mn-nat-traversal, the mapping doesn't change
      when the MN changes its CoA.  This is a huge benefit.

      The MN simply makes another tunnel to the currently used
      TTR.  The mapping only changes when a new TTR is used - and
      this is typically desirable if the MN moves more than about
      1000km or more from the currently used TTR.  So most MNs could
      be hopping around various access networks in a city, or medium-
      sized country, changing their CoAs second-by-second - and using
      multiple CoAs simultaneously on multiple access networks - and
      will still use the same TTR, with consequently no need for
      mapping changes from one month to the next.

  2 - The MN typically uses a nearby TTR, so there is little stretch.

  3 - If the MN suddenly finds itself connected far from the TTR,
      it still makes a tunnel to it, and continues operation.  It is
      up to the TTR company, with its tunneling software in the MN,
      to figure this out and get the MN to tunnel to a closer TTR.
      When this has been done, the mapping can be changed to the new
      TTR.  Since both tunnels can be active at the same time, there
      is no loss of data as the mapping changes from one TTR to the
      other.

  4 - A single 2-way tunnel handles all traffic in and out of the
      MN.

TTR Mobility has been fully documented for nearly two years:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

     TTR Mobility Extensions for Core-Edge Separation Solutions
     to the Internet's Routing Scaling Problem
     2008-08-25
     Robin Whittle, First Principles, Rosanna, Vic, Australia
     Steven Russert (previously of) Boeing Phantom Works, Seattle.

Since then, it has received little attention.  However, with the 07
and 08 revisions a week ago, Fred Templin's IRON architecture has
been significantly redesigned to use TTR Mobility principles for all
networks, not just mobile networks or MNs:

  http://tools.ietf.org/html/draft-templin-iron-08

I am still reading this, and am discussing it with Fred on the RRG list.

  - Robin

---

From: Michael Menth <[email-masked]>
Date: Tue, 13 Jul 2010 18:28:52 +0200

Hi Robin,

> the contrary - that such packets would be dropped.
We assume that the MN encapsulates the packets with the local 
care-of-address obtained from the host network and, therefore, outgoing 
packet have a source address that falls into the correct address range 
so that they are able to cross the border router after NAT has been 
performed. See Fig. 4 in
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth10-Sub-2.pdf 
for illustration.

Regards,

    Michael

-- 
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Robin Whittle <[email-masked]>
Date: Wed, 14 Jul 2010 20:34:07 +1000

Hi Michael,

> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth10-Sub-2.pdf

Sorry, what I wrote was confusing.  I wasn't suggesting that your
approach to tunneling wouldn't work.

What I meant was that for LISP or anything like it to work with the
MN behind NAT, the MN needs to use one or more tunnels for all
traffic packets - and that you might as well use a single two-way
tunnel for all of it.

I just remembered that mobility was ruled out of scope for the WG and
therefore this list.  As far as I know, this is still the case,
though I notice it is to be discussed in Maastricht.  Unless I hear
otherwise, I will continue this discussion off-list.

  - Robin