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

From: Robin Whittle <[email-masked]>
Date: Thu, 22 May 2008 11:04:10 +1000

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 [email-masked] 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

---

From: "Tony Li" <[email-masked]>
Date: Wed, 21 May 2008 19:25:25 -0700

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

Yes.

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

Well, that's a matter of opinion, not a matter of fact.

Now, can we please stop discussing proposals?

Tony

---

From: "Tony Li" <[email-masked]>
Date: Wed, 21 May 2008 19:25:25 -0700

Yes.

Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 May 2008 22:33:00 -0400

Robin, your note assumes several agreements which have not yet been reached.

We have by no means explored all of the host based or transport based 
solutions.  The WG has not agreed that the solution must be on a site 
level.  There are certainly advantages to site level solutions, but it 
is not a done deal.

We have not even had any serious discussions about whether IPv6 only 
solutions are worth considering.  You simply assert that we must have v4 
as well as v6 solutions.  Again, there are good reasons to want 
solutions for both spaces.  But there are also strong arguments in terms 
of deployment and actual need that indicate that a v6 only solution may 
be more deployable and more useful.  I personally wonder if we might 
well be better off with a v6-centric solution.

You list several further "must not" that are not yet working group 
agreements.  Several of them look like good ideas.  But it is a long 
step from "good constraint if we can meet it" to "must not."

Yours,
Joel M. Halpern

---

From: Robin Whittle <[email-masked]>
Date: Thu, 22 May 2008 13:26:49 +1000

Hi Tony,

> thinks it could be practical?

OK - I assume this means you think Six/One Router is practical, or
could be made so - however defined.

How is it practical for the 2nd translation router (in the
destination provider network, like an ETR in map-encap) to handle
this situation?

  Host A in network NA sends two packets to hosts B and C, both of
  which are in network NB and are served by a 2nd translation router
  R2.

  In order to get to R2, the packets are intercepted and translated
  by R1, presumably in NA.

  This translation involves changing the destination addresses of
  the two packets from B and C to R2 and R2 respectively.

  How can R2 distinguish between these packets it receives and
  know which one to send to B and which to send to C?

I am assuming there is no encapsulation, no options header etc.

It seems the only way this could be done is by R1 sending some
supplementary information to R2, which R2 would need to receive
correctly before it could correctly handle these two packets.  I
don't see how sending extra packets like this could be regarded as
robust and efficient enough to be "practical".

Christian Vogt presumably has powerful reasons for needing deep
packet inspection and modification in order to make Six/One Router
work in the "transition period" - which in fact would last forever.
 Can you imagine a way he could do this without deep packet
inspection and modification - or how any purely translation-based
scheme could work without this?

Likewise his need to alter DNS responses.

> Now, can we please stop discussing proposals?

We are discussing eliminating areas of the design space.  In order
to do so, I think it is pertinent to discuss what proposals that
space contains at present, as part of discussing what it could ever
contain.

If you or anyone else would like to debate my critique of Six/One
Router:

  http://psg.com/lists/rrg/2008/msg01283.html
  http://psg.com/lists/rrg/2008/msg00533.html

I think this would be a good step towards establishing whether this
translation approach is "practical" (however defined) and whether it
is feasible for anyone to develop another translation based proposal
in the RRG time-frame which is "practical".

I doubt that I can constructively discuss eliminating or keeping
open certain parts of the design space without discussing the
existence or non-existence of proposals in those spaces, and to what
degree they could possibly be widely adopted.  Since you are
co-chair, I interpret this as an instruction not to discuss specific
proposals as part of discussing whether or not to rule out certain
parts of the solution space - so I may not have much more to say on
this.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Thu, 22 May 2008 13:41:53 +1000

Hi Joel,

> level.  There are certainly advantages to site level solutions, but it

Perhaps this would be a good thing to settle soon.  The question of
which way to branch at the "map-encap / translation / transport"
junction depends in part on how acceptable a purely host-based
approach would be.

I can't see how any scheme which requires host changes could be
widely enough adopted to solve the IPv4 routing scaling problem, so
I think we can safely discount any part of the solution space which
doesn't give the network administrator the tools they need via
routers etc. rather than by changing hosts, to isolate their hosts
from changes in routing, multihoming service restoration
adaptations, moving the network to a new provider etc.

> as well as v6 solutions.  

I assumed this was agreed, but apparently not.  I raise the prospect
of IPv6-only solutions in a separate message: "What do we have
consensus on?"

> Again, there are good reasons to want

I completely disagree.  If the RRG and later the IETF comes up with
an IPv6 only solution, it won't help at all with the IPv4 situation.
   I can't see how current IPv4 end-users will be tempted or able to
switch to IPv6-only addresses in sufficient numbers in the next
decade to alleviate the IPv4 routing scaling problem.

> step from "good constraint if we can meet it" to "must not."

I wrote what seemed sensible to me.  I was not implying it was
consensus in the RRG.

 - Robin

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 May 2008 16:19:49 +0200

On Thu, May 22, 2008 at 11:04:10AM +1000,
 Robin Whittle <[email-masked]> wrote 

>                 proposals are all Map-Encap.

I am not sure I agree with your classification. Where do you put HIP?
 
> traffic packets.  
...
> universal adoption as the RRG will be proposing, 

You may not like it but saying it is impossible is a bit strange since
currently, most users today access Internet through a NAT box which
typically works that way (with the limitations you mention).

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 May 2008 11:24:57 +1000

Hi Stephane,

> I am not sure I agree with your classification. Where do you put HIP?

AFAIK HIP is not under consideration to solve the routing
scalability problem.  It is not mentioned in the RRG's wiki.  It is
not compatible with current applications or operating systems, so
even if it solved the routing scalability problem, I don't see how
it could be a practical solution, since there is no way we are going
to be able to convince everyone to create and use HIP-compliant
applications and operating systems to the exclusion of what they use
now.

> typically works that way (with the limitations you mention).

NAT does not involve understanding application protocols for the
purpose of finding raw IP addresses being communicated between
applications so that those addresses can be rewritten.  I understand
that Six/One Router involves its translation routers doing this,
which I think is wildly impractical.

 - Robin