RE: Host-based may be the way to go, but network controls are neccessary

["Aldrin Isaac" <aisaac@bloomberg.com>]

Craig,

FYI, I am merging our discussion back into multi6 mailing list.

% From: Craig A. Huegen [mailto:chuegen@cisco.com]
% Sent: Tuesday, November 19, 2002 6:21 PM
% To: Aldrin Isaac
% Subject: RE: Host-based may be the way to go, but network
% controls are neccessary

% > economic incentive for them to do that.  IMHO, DFZ hole-punching
is
% > the only "true" network-based multihoming solution that will
prevent
% > loss of transport-level connectivity and that will still preserve
the
% > end-to-end principle in it's purest form.  Every other other
% > network-based multihoming will have some hacks in it.
%
% I'm not sure I can dismiss other alternatives as quickly. I think
that a
% multi-homing service in the network could be created (perhaps using
DNS)
% that a host consulted with before opening a connection to determine
the
% right source/dest addresses to use might be a solution here that is
a good
% hybrid.
%

An enhanced network-aware DNS approach is definitely a clean way to do
valid source address selection.  In order for it to work, this service
would need to know the current site-exit for every external prefix in
the site's network routing table (::/0 included), and the source
prefixes that that site-exit will honor.  This is certainly not
impossible.  I run gated on several unix systems and could easily hack
out a non-DNS prototype that could do this simply by (1) having a
table of all the site-exits and the prefixes honored at those
site-exits (2) looking into the routing table and seeing who's the
current site-exit for a requested destination (3) respond with the
prefixes associated to that site-exit.

There are a few short-comings though.  For any one destination, this
approach can only reliably provide prefixes that will be honored at
only one site-exit (anything more raises some complex issues).  This
means that (1) there is possibly no ability to load-share over
multiple ISPs (2) offers no option for host-based high-availability to
destinations outside of the site, (3) works great outbound but does
not offer a good solution for inbound connections (4) i'll stop here
so I can reserve time and brain energy for the rest of my work day.

% > Keep in mind that you don't *have* to implement multi-homed
desktops.
% > You don't have to propogate all PA prefixes everywhere.  You only
need
% > to propogate certain prefixes to certain zones in your network
% > depending on the ISPs you wish to service that zone.
%
% In my case, I have a requirement for multi-homed desktops
everywhere.  Our
% network is cleanly split into multiple zones based on one of five
major
% Internet access points.  Each access point has at least 2 providers
(or
% will shortly).  So overall, globally we have 15 provider connections
for
% major access points -- I don't use all 15 everywhere; I use 4 in SJ,
3 in
% Raleigh, etc...
%

I know of a way to control proper site-exit routing regardless of
which source address a host uses.  I need to dwell on it for some more
time before I can present it.  It's simple and a form of it already
exists, and should at least offer hope for a clean network-controlled
host-independent site-exit routing solution.  Given you could route
packets to the correct site-exit(s) regardless of what source address
your hosts should choose, then the only control neccessary would be to
announce selected prefixes to the various zones of your network such
that they will only route via site-exits of your choosing.

I still stongly believe that internal and private communication should
happen via "private" non-internet-routable global-addresses, i.e. if a
subnet has no need to have true end-to-end connectivity with Internet
hosts then it should not have to have an Internet (PA) prefix.
Someone will have to provide me a strong unslanted complete argument
against it for me to believe otherwise.

-- aldrin