[RAM] 2 ETR strategies, including in the host

Here are some thoughts on the various ways the ETR function can be
implemented.  I am thinking about Ivip but probably a lot of this
would work for LISP too.

ETRs in general don't need to be linked to the Ivip system itself
(ITRs, the central database, however users control the central
database and however ITRs keep up with the central database), so
they are freewheeling devices - or simply functions, such as an
ETR function in a host.

I will give these strategies or scenarios names so I can refer to
and compare them.

In keeping with the diagrams in my previous message regarding ITRs,
I generally assume the sending host is on the left, in some other
edge network, and that the host with the Ivip-mapped address is on
the right.

If the hosts on the left have Ivip-mapped addresses, then there
would be a similar process occurring for packets going in the
return path, but using ITRs in or near the right edge network and
ETRs within the left edge network.

  IR    Ordinary internal router.

  BR    Border router - connects to the global BGP system.

  ETR   Egress Tunnel Router

  H     Hosts with ordinary BGP-routable IP addresses, either
        PI or PA.  For instance desktop machines and servers.

  IH    Hosts with one or more IP addresses which are mapped
        by the LISP/Ivip system.  These could be routers too.

ETR-internal
------------

                     .............................
                   .
Internet          .   Edge network
                  .
              \   .   H   IH     H
               \  .  /    /     /
                \ . /    /     /
           ------BR-----IR---IR--IH
                  . \  / \   /
                  .  \/   \ /
                  .  IR---ETR1---IH
                  .         \
                  .          \
                   .         IH
                     ..............................

There are one or more ETRs inside the edge network.  Hosts with
Ivip-mapped addresses may be connected directly or via other
internal routers.

The ETR function is probably performed in a router, but
in principle it could also be done in a server which has a single
connection to the local network.  These could be very cheap - just
a PC motherboard with a Core2 Duo CPU or its AMD equivalent, running
Linux, BSD etc. and some suitable ETR software, using the gigabit
Ethernet interface(s) on the motherboard.

ETRs in general, probably need to be administered so that when they
decapsulate a packet, they check the destination address of the
resulting packet is within a list (list of IP addresses and
prefixes) prepared by the administrators of Ivip-mapped addresses
of hosts in the local network.  Otherwise, the ETR can be a cause
of annoyance, security risks etc.

Administering all the ETRs in an edge network in this manner would
be a significant chore and a likely cause of trouble.  Any automatic
discovery system by which hosts could find ETRs, or some edge
network management system, by which they could tell the local
system of their Ivip-mapped address(es), would need to be secure.

Probably each host needs a username and password so it can log
into the network management system and tell the system the one or
more IP addresses it has via Ivip. Then the system would tell the
host one or more IP addresses of ETRs to use, with a "lease time" or
some other mechanism by which the local network can tell these
hosts that an ETR is down, or that they should use another one.

Then the ETRs would be to forward decapsulated packets
which have the destination address(es) which the host registers.

However, only in the case of a singlehomed scenario should the edge
network's local routing system forward packets by their Ivip-mapped
address (I mean the original IP address by which the host is reached
worldwide) to the host.  In this case the ETR and host (or link to
the remote host, client site router etc.) need not be directly
connected, if the local routing system routes all "raw" packets to
the host.

In a multihomed or mobile situation, the routing system must never
attempt to route raw packets to the host, destination router etc.  I
explain this below in the section "Multihoming and Mobile Maxim
regarding ITRs".

So in multihoming scenarios, the ETR must be directly connected to
the host or the link to the host, customer site router etc.  In
mobile scenarios, the ETR function is performed by a TTR which has a
two-way tunnel to the mobile host at its care-of address, so there
is no need for the edge network's routing system to be aware of the
mobile host's Ivip-mapped IP address.

Back to the question of how an ETR or a management system for an ETR
or an ETR management system in the edge network can know whether it
is reasonable or not when a host requests that ETRs decapsulate
packets to the Ivip-mapped address the host tell it.

It wouldn't help to require the ETR or the local system to ensure
that these addresses were currently mapped in the Ivip system to
be tunneled to this ETR, or any other - because maybe the host
already has a link and a working ETR on ISP-A and this is ISP-B,
with which it is setting up a link and an ETR, so it can switch
over to this one if the ISP-A arrangement fails.

It is not feasible to have the ETRs ensure that encapsulated
packets arrive from "ITRs", because there could be hundreds of
thousands of ITRs in the Internet.  Furthermore, it is likely and
desirable that many hosts will act as their own ITRs (ITFH), sending
encapsulated packets directly to the ETR address.

Having one or more internal ETRs takes the load off the border
router, which may be the conceptually neatest place to decapsulate
packets.  However, except for a multihoming situation, there needs
to be a way that each ETR can get packets directly to the
destination host, without relying on general support from the
routing system.  Maybe the ETR can be made to send the packets with
some kind of explicit routing arrangement, which won't cause other
packets with these raw Ivip-mapped addresses to be sent along the
same path.

If there are hosts in this edge network doing their own ITFH
(Ingress Tunnel Function in the Host) function, that function is
unlikely to be smart enough to realise when the destination host is
actually in this edge network, so the packets could ideally be sent
without encapsulation.  To be this smart, the ITFH would need to be
kept up to date with all the Ivip-mapped IP addresses in the local
network, which is unrealistic and also arguably a leak of
information about those other hosts.  Such knowledge, to save
encapsulation and to rely on a suitably configured edge network
routing system, would only be valid in a singlehomed scenario.

So the ITFH function should always encapsulate the packets and let
them be forwarded to the nearest ITR.  Only the ITR really knows
which ETR the packets should be tunneled to.

Let's say an end-user has a host or a router with one or a bunch of
IP addresses, multihomed by two ISPs ISP-A and ISP-B.

In both networks, the ETR needs to be ready to send decapsulated
packets to the link which leads to the user's site.  Normally, one
might think, this would be done by the ETR being somewhere in the
edge network and the edge network's routing system forwarding the
packets appropriately.  That would be OK for a singlehomed
situation, where if the destination with the Ivip-mapped address(es)
goes down, the host isn't any other way that destination could be
reached.  It is not OK for multihoming.

Let's say the end-user is currently using ISP-A.

ISP-B's network has already been set up to forward packets to the
link to the customer, from ISP-B's ETR (or multiple ETRs) and from
any hosts in ISP-B's network.

So far, everything is fine provided the end-user's host or router
accepts incoming packets on both links at once.

But what if the link to ISP-A fails?

Some automatic system outside these edge networks would detect this
and switch the Ivip-mapping to ISP-B's ETR.

After the switchover, what about packets to the Ivip-mapped address
which were generated by hosts in the edge network of ISP-A?  They
would be forwarded to the dead link.

The only way I can see of resolving this is what I will call the

Multihoming and Mobile Maxim regarding ITRs
-------------------------------------------

   Except in single-homed settings (where any change to another
   ISP's ETR will be slow and accompanied by change in the old ISP's
   internal routing system) all packets addressed to Ivip-mapped
   addresses - except those exiting an ETR to be sent directly to
   the destination host or router - MUST pass through an ITR: ITRD,
   ITRC or ITFH.

from which it follows that:

   In all but a single-homed situation, the ISP's internal routing
   system MUST NOT try to forward packets addressed to the
   Ivip-mapped address directly to the host, because the link to the
   host may be dead, and the ITRs will soon know how to tunnel the
   packet to an ETR with a good link.

Only the ITRs have the up-to-date knowledge of which ETR and
therefore which link to use in a multihoming situation.

It may well be that the ITR is also the ETR, in which case the
packet would not need to be encapsulated, but could simply be
forwarded to the destination host or router.  But it this should be
done only when the Ivip-mapping says that this same router is
currently the ETR.

Assuming a multihoming scenario, this situation of encapsulated
packets being generated in the same edge network, either by nearby
ITRs or directly in the sending hosts with ITFH, is a good argument
for there being multiple ETRs all over the edge network, and the
host choosing one which it is close to.

If the edge network only has one ETR, far away from the host, then
packets tunneled from ITFH hosts and ITRs near the host would have
to traverse the edge network to get to the ETR.

So except for singlehoming (where there could easily be multiple
ETRs in the edge network with the edge network's local routing
system forwarding encapsulated packets to the destination host), the
local routing system must not attempt special treatment of packets
which are addressed to Ivip-mapped addresses which the local network
is configured to support - because maybe the link to the host is
dead and the packets need to be tunneled to an ETR in another edge
network.

Back to the characteristics of ETR-internal:

Host requirements:

   The host has only (or at least needs only) its Ivip-mapped
   address.  There is no need for any special software.
   (The host could perform its own ITR functions, but that is
   a separate issue.)

Local routing system:

   Unless the edge network administrators know for sure the host
   or the link to the remote host, router etc. is single homed,
   the edge network must not attempt to route packets directly to
   that host.  It should always treat them like the rest of the
   packets addressed to Ivip-mapped master-subnets: forward them
   to the nearest ITR (ITRC or ITRD).  Only the ITRs really know
   what to do with the packet.

   It is probably easier to forget the idea of local routing
   system support for the Ivip-mapped addresses of even
   singlehomed hosts or links to customer sites.  How is the
   edge network to know the customer doesn't have another link?

   Creating two classes of host would be a pain, and anyway
   the local routing system already has its hands full, without
   catering to a large and perhaps rapidly changing set of addresses
   and small subnets which are used by Ivip-mapped hosts.

   The local routing system, or at least the border router, does
   need to recognise packets sent from the host using its
   Ivip-mapped address, and allow them to be forwarded internally,
   or to the BGP system, in either case to the nearest ITR if the
   destination address is within an Ivip-mapped master-subnet.

ETR - host relationship:

   Assuming no special exceptions are to be made for singlehomed
   hosts or links to customer sites, the ETR needs a direct way of
   sending packets to the destination host.

   Therefore, the ETR should be close to the destination host.

   If there are alternative ETRs so the mapping can be changed to
   select a different ETR if the first one fails, then both ETRs
   need a direct way of getting packets to the destination host.

ETR-border
----------

                     .............................
                   .
Internet          .   Edge network
                  .
              \   .   H   IH     H
               \  .  /    /     /
                \ . /    /     /
           -----ETR1----IR---IR--IH
                  . \  / \   /
                  .  \/   \ /
                  .  IR---IR-----IH
                  .         \
                  .          \
                   .         IH
                     ..............................

This differs from ETR-internal in the following ways:

The border router has yet another pile or work to do - this is
probably only acceptable for smaller networks where the border
router is not so busy.

Unless the destination host is directly connected to the ETR border
router, then the ETR-border router needs some robust, independent,
way of sending packets to the host.  It cannot rely on the local
routing system, because as described above, the local routing system
must forward all packets addressed to any Ivip-mapped address to the
nearest ITR.

If the edge network has a single ITR function and a single ETR
function, both integrated in the border router, then this
simplifies the whole system.

ETR-host
--------

                     .............................
                   .
Internet          .   Edge network
                  .
              \   .   H    *IH   H
               \  .  /    /     /
                \ . /    /     /
           ------BR-----IR---IR--*IH
                  . \  / \   /
                  .  \/   \ /
                  .  IR---IR-----*IH
                  .         \
                  .          \       * = Host OS
                   .          *IH        ETR function
                     ..............................

Assuming Ivip or similar becomes widely deployed, it may make
sense to add a little piece of IETF-standardised ETR functionality
to host operating systems.  This would decapsulate packets and
drop all packets which were not for the one or more of this
host's Ivip-mapped addresses.  So this is not to be an ETR for any
host but the host it runs on.

This in some ways resembles mobile-IP because the host needs a
care-of address, which is a public, BGP routed, address (not behind
NAT - though mobile-IP can work with the host behind NAT), to which
the ITRs tunnel the packets.

ETR-internal and ETR-border do not require the destination host to
be changed in any way.  The destination host only has its own
(Ivip-mapped) IP address(es).

This has a number of advantages:

1 - Less - or no - need for ETRs in the edge network.

2 - No extra packet handling or longer paths to go via
    the ETR.

3 - No need for one or more ETRs to have pipes, tunnels or
    whatever to traverse the local network to get packets
    to the destination host.

4 - CPU power and OS functionality in the host is free, which is
    not the case in routers!  (However, an ETR could be built
    with a standard Linux box with suitable software, for very
    low cost.)

As with ETR-internal, unless there is some other arrangement, the
edge network's routing system does need to allow packets out of the
host, with the source address being the Ivip-mapped address, to be
forwarded to:

1 - A host in the edge network.

2 - An ITR if the destination address is Ivip-mapped - which
    would be covered by the next point if there is no ITR
    in the edge network.

3 - Out through the border router into the BGP system.

"Some other arrangement" could mean a one way tunnel from the host
to some router somewhere else (that is, to a TTR - Translating
Tunnel Router, as I mentioned in messages starting on 17 June) which
would decapsulate the packets tunneled from the host, be happy with
this sending address and so forward them to wherever they needed to
go.  That would resemble an Ivip-mobile arrangement in some ways.

Normal Ivip-mobile:

                                        Mobile host, with
                                        care-off address,
                                        perhaps behind NAT,
                                        creates 2-way tunnel
                                        to TTR.
Sending
host --------->----ITR~~~~~~~~TTR===<===>==IH
                              /
                      <------/

By the way, even if the mobile node was on an Ivip-mapped address,
or behind a NAT which uses an Ivip-mapped address, it can still make
a tunnel to any TTR it chooses, and have its own Ivip-mapped IP
address via the ITRs beaming packets to whichever TTR it, or some
central monitoring system, chooses.

ETR-host with second tunnel to another router for
outgoing traffic - the second router is probably
outside the edge network the host has its care-of
address in.

                                         * = ETR function
                                         in host.  Host also
                                         care-of address, but
                                         can't be behind NAT.

Sending
host --------->----ITR~~~~~~~~~~~~~~~~>~~~~*IH
                                            /
               <----"2nd router"~~~~~<~~~~~/

                                         Host creates one-way tunnel
                                         to 2nd router, probably
                                         outside the edge network,
                                         so it can get its packets
                                         out without having
                                         permission from the edge
                                         network.  This is good for
                                         simplicity but bad for
                                         efficiency if the
                                         destination address is
                                         within the same edge
                                         network.

In both cases, there is no need for support from the local network.
  The second router needs to be prepared to forward packets to the
Net with the source address which is an Ivip-mapped address.

ETR-host only works if the host has a normal, globally reachable,
BGP-routed IP address.  It won't work if the host is behind NAT.

 - Robin         http://www.firstpr.com.au/ip/ivip/

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram