Subject: [RRG] Consensus? Router-based Translation schemes can only work with duplicate address space

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 19:55:54 +1000

Here is another thing I think we should agree on.  This only applies
to translation schemes where the translation is done by a router,
rather than be upgraded facilities in the hosts themselves (such as
SHIM6 or Six/One - not Six/One Router).  In other messages I argue
that trying to solve the routing scaling problem with host upgrades
is never going to work, not least due to the difficulty or
impossibility of upgrading all hosts and to the difficulty of
securely managing their behavior in the centralised manner that most
end-user networks would require.

Map-encap systems add extra data to each packet in order to
transport it across the DFZ without routing scaling problems, and so
that the receiving router (the ETR) can figure out how to handle the
packet.  This is done by the full packet being sent verbatim, and
the outer header existing purely to get the inner packet to the ETR.

A translation scheme does not make packets any longer, which might
avoid some nasty problems map-encap schemes face with Path MTU
Discovery, overly large packets getting dropped or fragmented in the
tunnel etc.

A translation scheme involves one router (R1 in what follows)
changing the destination address of the packet so that it can be
transported across the DFZ, without routing scaling problems, to a
second router (R2), near the real destination host.  R2 then has the
task of figuring out the proper destination address of this packet,
so it can forward it correctly.

For multihoming (portability as well?) one way of doing this for an
address space X is to have two or more address spaces Y and Z of the
same length as X, and have R2 receive all packets addressed to those
Y and Z spaces.  When the sending host (near R1) generates a packet
addressed to some destination host at (X + N), R1 rewrites the
address to (Y + N) or (Z + N).  Then R2 has no difficulty
reconstituting the original packet by altering its destination
address to (X + N).

This may be a practical approach in IPv6, since there is plenty of
address space.

However, in the context of the IPv4 address shortage, it is
completely impractical in IPv4.

For a router-based address translation scheme (such as Six/One
Router) to work without duplicate address ranges, there needs to be
a practical method of R2 reconstituting the packet it receives.

Without duplicate address spaces, R1 will send all packets to R2's
hosts by changing the destination address to that of R2.

There is no "N" in this, so R2 has no way of knowing from the packet
itself which host it needs to be forwarded to.

The following scenario exemplifies the problem which such a scheme
faces.

   Host A in R1's network sends a packet to host B and an
   identical packet to host C.  Both B and C are in R2's network.

   R1 rewrites the destination address of both packets to R2's
   address.  What would the scheme have to do in order to enable R2
   to know how to reconstitute the destination address?  All the
   options seem so onerous and troublesome that I argue that this is
   completely impractical.

   For instance, R1 could send a separate "info" packet for each of
   these traffic packets, telling R2 the B or C address, and somehow
   enabling R2 to unambiguously identify which incoming packet the
   information applies to.

   This raises problems of reliability and packet loss/delay.  It
   also raises some security problems, since an attacker could spoof
   the info packet, making it get to R2 before the real info packet
   from R1.  To prevent this, there would have to be some fancy
   authentication  arrangements - but how could this be done without
   PKI or without  multi-packet exchanges of nonces etc.?  Such
   arrangements would also delay initial packets in a new
   communication flow, and further contribute to  vulnerability of
   the system to packet loss.

   This approach and its required authentication arrangements also
   involves R2 storing a large amount of state and doing many
   complex operations.

This looks like a robust theoretical argument why a router-based
translation scheme can never be efficient or robust unless it uses
duplicate address space - which means such an approach cannot be
practical for IPv4.

  - 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: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 05:39:44 -0700

Robin,

While I am impressed with your stamina, I'll save folks time here
and say that again I disagree with many of the premises that
you believe.

- Translation schemes might make packets longer, depending
  on the design.  Consider IPv4::IPv6 translation for example,
  where the packet header increases significantly in size.

- We agree that tunnelling has various issues, but they are part
  of the architectural tradeoffs for the group to evaluate.  All
  proposed approaches have tradeoffs, as near as I can tell.

% This looks like a robust theoretical argument why a router-based
% translation scheme can never be efficient or robust unless it uses
% duplicate address space - which means such an approach
% cannot be practical for IPv4.

Kindly consider NAT/NAPT/similar devices, which many folks dislike,
but which continue to be widely deployed and used -- with many
folks finding the tradeoffs acceptable, the deployment efficient
enough and robust enough.  These boxes are fundamentally
translation systems and are a counter-example for your
bold claim quoted above.

Cheers,

Ran

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 01:29:07 +1000

Hi Randall,

>   where the packet header increases significantly in size.

I was referring to translation schemes for the routing scaling
problem.  The only such scheme I know of is Six/One Router.  One of
the advantages of this is that it does not alter the length of the
packet.

>   proposed approaches have tradeoffs, as near as I can tell.

OK.

> translation systems and are a counter-example for your

I am only discussing a scheme such as Six/One Router being used
without multiple address spaces.  This is not at all like NAT.  My
example is sufficient to show that the two (three in may example)
communicating hosts have real public addresses, but that these
addresses are not part of the DFZ BGP routing system.  The task of
R1 is to get the packet to the appropriate router R2 for wherever
the destination host's network is currently connected.

If there are other translation schemes which will solve the routing
scaling problem, I hope someone will discuss them.  Likewise, if I
have misunderstood Six/One Router, or if my example is inadequate, I
hope someone will correct me.

 - Robin