[RRG] Six/One Router: why have bilateral mode? Referrals . . .

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

Short version:  I think I now understand why Unilateral mode
                is needed between hosts in upgraded networks.

                The sole reason seems to be referrals from
                hosts on ordinary addresses - not in upgraded
                networks, not using the new kind of Edge address
                space provided by Six/One Router.

                Still, I don't see how referrals can be made to
                work in general, since host A having been referred
                to host B by B's transit address will (in many
                higher level protocols) tell B this address, and
                B will not recognise it, since hosts have no idea
                about transit addresses.


Hi Christian,

In the "Renumbering..." thread you answered my question about why
Six/One Router has Bilateral mode.

  http://psg.com/lists/rrg/2008/msg02208.html   RW
  http://psg.com/lists/rrg/2008/msg02214.html   CV

I also raised this question in my tentative critique:

  http://psg.com/lists/rrg/2008/msg02034.html
  http://psg.com/lists/rrg/2008/msg02141.html
  http://psg.com/lists/rrg/2008/msg02149.html  < Charts

Message 2149 has charts depicting my understanding of the three
modes of operation.

The one we are referring to now is Fig 5 Unilateral with both
networks upgraded.

I didn't understand why this was necessary.  I would have thought
that all that is needed is Bilateral mode (Fig 2) when both hosts
are in upgraded networks.

In this case, both hosts have End User addresses.  These are real,
portable, multihomable, permanent addresses the host uses no matter
what one or more ISPs its user network is currently using to access
the Net.  These addresses are not in any prefix advertised in BGP.
The transit addresses are advertised.

In Fig 2 Bilateral - Both networks upgraded - all is well.

The left and right hosts talk to each other using their E (Edge)
addresses only. They neither know nor care about transit (T)
addresses, or the existence of Six/One Router and its TRs.

I think the reason why Unilateral mode between two hosts in upgraded
networks is necessary is due to the weakness (I think) of the method
by which one host finds the address of the other via DNS.  I
understand the AAAA record carries the E address and the one or more
T addresses.  The host is assumed not to know about Six/One Router,
or which addresses are End user addresses or Transit addresses.

I think it tries to use the IP addresses in some random order, and
as soon as it finds one which works, it sticks with that.

(This sounds very slow - how long is the host to wait without a
response before it decides one address doesn't work and that it
should try the next?)

You wrote:

> Robin,
>
> you are referring to a packet exchange between two upgraded edge
> networks where the initiating host has used a transit address to
> reach the responding host.

Yes.

> In this case, the operation of Six/One Router causes both hosts to
> use a transit address for their respective peer *. You are asking
> why.  (Tell me if I didn't get your question right.)

That's right.

> [*] Noteworthy, as you are bringing up this question in the
>     context of renumbering:  Renumbering is not necessary
>     nevertheless.   Hosts in upgraded edge networks never see
>     their transit addresses themselves; only local edge addresses
>     are used within an edge network.  The transit addresses that
>     may appear within an edge network are exclusively remote.

I think it would be best if the host using DNS AAAA addresses never
found that a transit address worked.  It should only find that the E
address works.  If this can be assured, then there would never be a
need for Bilateral mode between two hosts in upgraded networks. Then
maybe you could get rid of the Bilateral/Unilateral bit, which at
present you apparently need, and which can only come from the Flow
Label bits.


> The reason why the initiating host sees its peer's transit address
> is simple:  The initiating host has chosen the peer's transit
> address as a destination address.

Yes, presumably from an AAAA record - and it finds that it works.

> So in order not to break the connection, it must see the peer's
> transit address also as a source address in received packets.

OK.

> The reason why the responding host sees its peer's (the initiating
> host's) transit address is more subtle:  By enforcing that either
> both or none of two peers see each other's transit addresses,
> Six/One Router can ensure that hosts see the right type of source
> address (edge or transit) in received packets.  Specifically, it
> enables a Six/One router at the edge network originating a packet
> to tell, based on the type of the packet's destination address,
> which type of source address the packet should have when
> eventually delivered to the recipient host.  The Six/One router
> can then accordingly set the Bilateral/Unilateral bit in the
> packet, so that the Six/One router at the recipient edge network
> knows whether it should rewrite the packet's source address back
> to an edge address, or leave it as a transit address.

Hmmm - if TRs are so smart, then I have another plan.

> Of course, since both edge networks are upgraded in the described
> case, the initiating host should preferably use the responding
> host's edge address.  And typically, it would do this because the
> standard destination address selection algorithm prefers edge
> addresses over transit addresses for hosts in upgraded edge
> networks.  This is due to the use of edge address type prefixes in
> Six/One Router, and the longest-prefix match in the address
> selection algorithm:  It makes a host in an upgraded edge network
> prefer destination edge addresses as destinations because the
> prefix of those addresses matches the prefix of the host's own
> address.

OK - I guess this is based on all E addresses being part of some
prefix such as 4::/3, and all T addresses being from outside that
prefix. So, by the process you describe, a host on the left using an
AAAA record for the host on the right would always choose the E
address, and not any of the one or more T addresses.

> However, the described case can still occur when the initiating
> host doesn't know the peer's edge address,  e.g., when it is
> referred to a transit address by SIP signalling.

OK, I understand that the sole reason for the existence of
Unilateral mode between two hosts with E addresses (two hosts in the
new kind of user network which always access the net via ISPs with
Translation Routers a their borders: upgraded networks) is to cope
with some other host telling it an IP address.

Let's say A is on the left, B is on the right and R is a referring
host somewhere else.

The problem arises when A is told by R about B, but only when R
gives B's Transit address (or one of its transit addresses) to A,
rather than B's real Edge address.

I think this would not occur when R was also on an E address -
assuming it got A's address via DNS or via B telling R its real E
addresses directly.

So I guess the problem only occurs when R gets B's address via some
other mechanism, such as:

  R is on an ordinary address in a network with no TRs. Then
  if B sends packets to it, R sees they come from B's transit
  address.  If R uses that address, rather than B telling it
  explicitly B's Edge address, then R will know B by its transit
  address and would tell A about B in these terms.

  Likewise if R was on an Edge address but got the Transit address
  of B from some other host which was not on an Edge address, by
  the process just described.


OK - I think I understand.  However it strikes me as inelegant that
you have to have this complexity.  It strikes me as a good argument
against Translation.


Looking at my charts, I see that the situation for the Left host in
my chart of Fig 4 (Unilateral,  Right host not in upgraded network)
resembles that of the Left host in Fig 5 (Unilateral, Both networks
upgraded) because the TR sees the destination address is not for an
Edge address.  The TR can't tell the difference between an address
which is in a Transit prefix or one which is in some prefix used by
hosts not using a Six/One Router style (Edge) address.

In both cases, the TR translates the source address, but not the
destination address, and sends the packet with the U/D flag set to
"U" for "Unilateral".

The packet is forwarded to the destination host. There is no other
TR in the path.  The state of the U/D flag is ignored.

In the bottom part of my chart for Fig 4, I show a packet coming
from an ordinary host (not on an Edge address) to the host on the
left, which has an Edge address.  The destination address of the
packet is the Transit address of the host on the left.  When the
packet reaches the TR at the ISP for the left host, it recognises
that this destination address is a Transit address, and it knows
which Edge address to rewrite it to.  So this is what it does.

The state of the U/D flag is not clear - since the packet was sent
by a host which does not know anything about Six/One Router, and the
packet has not been through a TR on its path to this TR/.

It does not rewrite the source address, because . . . I guess
because it looks it up in the mapping system and the response is
that it is not a transit address.

So there seems to be no need for the U/D flag in Unilateral mode
with a host which is not in an upgraded network.  The TR doesn't
need to set it for outgoing packets, since no TR will be there to
translate the packet.  It can't use the flag on the packet from the
ordinary host, because there has been no TR to set it.

So it seems you need the U/D flag only for Unilateral Mode between
two hosts in upgraded networks, and you only need that mode because
of the problem of referrals from hosts which are not on an Edge
address (and so not behind a TR) and which use a packet's source
address (a transit address) for the IP address they use for a
referral, rather than the host's own Edge address which it must
somehow communicate in the higher level protocol.


This whole business of trying to make Six/One Router interwork with
non-upgraded networks seems like a nightmare to me.

Even if the system works as just described, there are bound to be
problems.

As described, the referral from some host R to A, telling A about B,
but referring to B by its Transit address (or one of its Transit
addresses) and not by using B's Edge address, will enable A to send
a packet to B.

However now A thinks that B's address is its transit address.  It is
reasonable to expect that the higher level protocol at work here
will involve A telling B what address it thinks B is on.  However, B
has no idea it has a transit address.  Properly written code at B
would reject any involvement with A, because A does not know B's
address.

I can't see how you can make referrals work.  This means I can't see
how you can make Six/One Router work - except for in an idealised
environment where all hosts use Six/One Router Edge addresses.  That
is completely unrealistic.  Any scalable routing system has to work
perfectly well with hosts in non-upgraded networks, otherwise it
will never be adopted to any significant degree.



I have an alternative to translation and to encapsulation - actually
two, one for IPv4 and one for IPv6.  Both require changes to all (or
almost all) DFZ routers - but I think the changes are pretty minor.
 The IPv6 approach is "Prefix Label Forwarding":

  http://www.firstpr.com.au/ip/ivip/ivip6/

This would involve no rewriting, or encapsulation overhead.  There
should be perfectly good backwards compatibility with ordinary
hosts, via OITRDs.  It should work with IPsec AH and there should be
no PMTUD problems.

At the least I would suggest it be a second mode of operation for
all ITRs and ETRs, so the system could be introduced incrementally
using encapsulation - and later switched to this "Prefix Label
Forwarding" once all the DFZ routers are upgraded.

Since there is no tearing hurry with IPv6, I think it may be
practical - and much simpler - to to upgrade the routers over a few
years and go straight to this "Prefix Label Forwarding" mode, and so
not have to bother with the complexities of encapsulation, coping
with encapsulation's PMTUD problems etc.

  - Robin



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