[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Aug 17, 2008, at 8:48, Robin Whittle wrote:


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.



Hi Robin,

you are right that Unilateral mode is needed between two upgraded edge
networks to handle transit address referrals.


               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.


B *will* recognize its transit address when being told about it by A,
based on standard NAT traversal mechanisms such as STUN, ICE (and TURN
if need be).  As a matter of fact, ICE would even prefer edge
addresses over transit addresses:  It prioritizes addresses that are
directly configured on an interface (i.e., the equivalent of edge
addresses) over addresses on the public side of a NAT (i.e., the
equivalent of transit addresses).


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.


Actually, the situation where host A in an upgraded edge network
chooses a destination transit address for host B in another upgraded
edge network does usually not arise when host A knows about host B's
complete address set (i.e., the edge address plus all transit
addresses).  In that case, the standard destination address selection
algorithm will make host A prefer host B's edge address over any of
host B's transit addresses.  Again, this is because of the
longest-prefix match in the destination address selection algorithm,
and the use of a unique (short) prefix for edge addresses.

Said situation rather may occur when host A is being referred to an
incomplete set of host B's addresses that does not include host B's
edge address.  Host A in this case has no choice but to select a
destination transit address.


(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?)


It's not slow.  Hosts in upgraded edge networks never have to try
twice because any destination address works for them, be it edge or
transit address.  Hosts in legacy edge networks may have to retry if
they happen to select a destination edge address.  But the
time-to-retry should be rather short, because the retry is efficiently
triggered by an ICMP Destination Unreachable message, which the first
core router sends when it finds that it doesn't have a route to the
selected destination edge address.


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.


Yes, I had thought about this.  One way to realize this would be:  If
a host in an upgraded edge network attempted to reach a transit
address from a peer in another upgraded edge network, it should
receive an ICMP Destination Unreachable message.  This would make the
host switch over to an edge address of the peer.  The reason I did not
follow this approach is because I wanted both address types to be
reachable from upgraded edge networks.  But the discussion with you is
making me reconsider, actually...

- Christian



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