[RRG] Arguments against Transport, Translation & Six/One Router

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

Short version:  Six/One Router looks completely impractical to me
                for several reasons at least.

                Is there anyone  other than Christian Vogt who
                thinks it could be practical?

                I suggest we eliminate "Translation" and "Transport"
                approaches from consideration, since 19 months after
                the RAWS workshop the only potentially practical
                proposals are all Map-Encap.


Currently we have several map-encap proposals: LISP-NERD, LISP-CONS,
APT, Ivip and TRRP.

These are all potentially "practical" - meaning they could be
introduced incrementally, without major disruption.  LISP and Ivip
have clearly defined arrangements for backwards compatibility, and I
think APT and TRRP could provide this as well.  The debate between
these is more about how well they would work, what other benefits
and costs they would have etc.

There are no "practical" proposals to solve the routing scaling
problem by souping up BGP or by replacing BGP with something else.

There has been discussion of "Transport" solutions.  If that means
SHIM6, this doesn't provide multihoming in a way which can be
managed per site, rather than per host - and it only works with IPv6
between hosts which are upgraded.  SHIM6 (or Six/One - not Six/One
Router) does not provide portability of address space between
providers, which is one of the major reasons for end-users wanting
their own PI address space.  Also, SHIM6 is not backwards
compatible, unless it is accepted that the multihoming can only be
provided for packets sent from from upgraded hosts.

What other "Transport" proposals are there?  If they involve
upgrades to hosts then they would never be widely enough adopted in
IPv4 to solve the routing scalability problem.  I think they must
involve new host functions, since that is where "Transport" happens.


The only other proposal for both IPv4 and IPv6 which is currently
being discussed is Six/One Router, which is a "Translation" proposal.

The packets retain their original length and have their destination
(and source?) address rewritten by the router which is broadly
equivalent to an ITR in map-encap.  The trick is to reverse this
procedure at the other end, the router in the destination network
which is comparable to the ETR in map-encap.  One approach to this
uses multiple parallel sets of routable address space for
multihoming the one set of end-user address space.  This might be OK
for IPv6 but will never be feasible for IPv4.

The task is to enable the ETR-like router to figure out how to
reconstitute the destination (and source?) address of packets it
receives from various sending hosts, via various Six-One routers,
for various destination hosts it is responsible for, when all these
packets arrive with the same destination address: that of the
ETR-like router.  The primary problem is that it cannot be
guaranteed that there will be enough information in each arriving
packet to distinguish between the same sending host sending similar
packets to two separate destination hosts, both of which are reached
via this one ETR-like router.  That information was lost in the
ITR-like router when it rewrote the different destination addresses
with the one address of the ETR-like router.


There has been discussion of option-headers to solve this problem -
but that increases the packet length just like map-encap, and would
not be at all practical since most (all?) routers in the DFZ can't
handle packets with option headers on their fast datapath.


Christian, you would have to convince me of several things before I
could contemplate Six/One Router being a potential solution to the
routing scaling problem:

1 - It needs to work fine for IPv4 as well as IPv6 - which means it
    can't require multiple subnets of routable space to correspond to
    the one subnet of end-user space.

2 - It needs to work without option headers.

3 - It needs to enable packets from non-upgraded networks to reach
    the destination host, as is achieved in Ivip with OITRDs (Open
    ITRs in the DFZ) and in LISP with PTRs (Proxy Tunnel Routers).

4 - It must not involve any routers looking into, or changing, the
    contents of traffic packets.

5 - It should not involve any changes to the DNS, such as to make
    the results for queries depend on the source of the query.

6 - Also, I think that the idea of the ETR-like router having to
    look up a remote database to figure out how to handle a received
    packet is a major problem, leading to packet delays and
    effectively to losses, unless the information can be found
    locally.

My initial objections to Six/One Router are here:

    Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6
    Interworking, Backwards-Compatibility  2008-02-27
    http://psg.com/lists/rrg/2008/msg00533.html


As far as I know, your continuing work on Six/One Router doesn't
address two major objections I (and I guess other people) have to
your proposal.

Firstly, as noted in the above-linked message, during the
"transition period", in order to provide backwards compatibility,
your proposal involves deep packet inspection and modification of
traffic packets.  The router needs to understand the application
protocol, find any IP addresses which may be contained in those
messages and change them to something else.

This is absolutely impossible to implement in a solution for
universal adoption as the RRG will be proposing, for reasons including:

  1 - No-one knows or can know all the details of all the
      application protocols.  (Your scheme would have the
      oppressive effect of making any new application
      protocol, which needed to communicate IP addresses, un-usable
      globally until all Six/One routers had been upgraded to
      successfully modify the packets.)

  2 - This deep packet inspection and modification is impossible
      in any encrypted protocol, or in one in which the message
      integrity is protected by cryptographic mechanisms.

  3 - The excessive amount of CPU power and volume of complex
      software (likewise the debugging nightmare) required to parse
      all traffic packets in order to determine their protocol and
      contents - and then to modify the contents.  This is entirely
      impractical.  (This assumes that the router could distinguish
      what the protocol was, packet-by-packet.  However, in many
      cases it would be impossible to determine what protocol was in
      use and which parts of the packet contained IP addresses.
      Only the two communicating hosts could determine that, and the
      router in the middle does not necessarily see all the
      communication and cannot maintain sufficient state to track
      what the hosts are doing.  Furthermore, the way the two hosts
      interpret the contents of traffic packets may be orchestrated
      by communication with one or more other hosts in a way the
      Six/One router cannot detect.)


Your requirement that DNS responses be modified at certain points in
the network sounds similarly nightmarish and at odds with common
sense.


Are you planning a version of Six/One Router for IPv4 without option
headers, deep packet inspection-modification and without the need
for altering DNS responses?

It is not good enough to say these things are only needed in the
"transition period".  Whatever the RRG proposes will always have to
co-exist with non-upgraded networks.  The new system will never be
adopted widely enough to solve the routing scaling problem if there
is any disruption to connectivity to and from non-upgraded network.
 Each one of the map-encap schemes, and your proposed Six/One Router
approach, will forever be in the "transition period" and will always
need to provide full backwards compatibility, without significant
disruption, for non-upgraded networks.


Is there anyone else who thinks that Six/One Router could be
practical, for IPv4 as well as IPv6?


Since I think Six/One Router is the only "Translation" proposal, and
because I think its problems are generally fundamental to the
central problem in any such translation scheme (trying to
reconstitute the packet at the "ETR-like" router, without extra bits
in the packet), I think the RRG can safely discount "Translation" as
well as "Transport" solutions, as it has already discounted "souping
up BGP" and "replacing BGP".

In the absence of any potentially practical proposals which are not
"Map-Encap", 19 months after the RAWS workshop and 9 or 10 months
from our reporting deadline of March 2009, I suggest we can safely
concentrate only on those solutions which are "Map-Encap": the
current ones and potentially any new ones.


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


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg