Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Why do you think host can not get infromation from the routing
> system?
> 
> In good old days when IPv4 routing table was not bloated, it was
> usual for UNIX box to run routed (in quite mode) even if a host
> is singly homed.

I recall reading a draft and slides which proposed using something like RIPv2
to distribute all the external routes from all the edges to the internal
routers and hosts (draft-ohta-e2e-multihoming).

Two issues with that aspect of that proposal: 
1. Folks seem to be want to put IP connectivity in smaller and smaller devices.
   Thus even though a laptop with a few hundered meg of memory can easily
handle
   the full routing table, it isn't obvious to me that it is a good thing
   assuming that all hosts that want to benefit from site multihoming will
   want to store the full routing table.

2. Efficiency/timeliness; when a different exit path should taken from
   a site for a given prefix/address this needs to be communicated rapidly
   and efficiently so that packets can use the new path.
   Sending all updates to the Internet routing table to all hosts is one way
   to convey this, but this means that updates to prefixes which nobody in
   the site care about might be communicated to hundereds of routers and 
   thousands of hosts.  And when a single or a few hosts indeed are interested
   in that update, it will potentially take some time to propagate, especially
   with a distance vector protocol as the distribution mechanism.

   A possible alternative is a packet driven approach at the border router
   where the arrival of a packet causes a signal back to the host.
   This signal could be either a source locator rewrite (which will return
   to the host in packets coming from the peer) or some new ICMP error
   directly to the host.

It would be good if the WG could explore the tradeoffs in this part of
the multihoming puzzle.

   Erik