Shim6, was: Re: filtering /48 is going to be necessary

William Herrin bill at herrin.us
Tue Mar 13 01:01:29 UTC 2012


2012/3/12 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>:
> William Herrin wrote:
>
>> When I ran the numbers a few years ago, a route had a global cost
>> impact in the neighborhood of $8000/year. It's tough to make a case
>> that folks who need multihoming's reliability can't afford to put that
>> much into the system.
>
> The cost for bloated DFZ routing table is not so small and is
> paid by all the players, including those who use DFZ but do
> not multihome.

Hi,

http://bill.herrin.us/network/bgpcost.html

If you believe there's an error in my methodology, feel free to take
issue with it.


>> Often overlooked is that multihoming through multi-addressing could
>> solve IP mobility too.
>
> Not.
>
> What is often overlooked is the fact that they are orthogonal
> problems.

I respectfully disagree. Current mobility efforts have gone down a
blind alley of relays from a home server and handoffs from one network
to the next. And in all fairness, with TCP tightly bound to a
particular IP address pair there aren't a whole lot of other options.
Nevertheless, it's badly suboptimal. Latency and routing inefficiency
rapidly increases with distance from the home node among other major
problems.

However, there's another way to imagine the problem: Networks become
available. Networks cease to be available. No handoff. No home server.
Just add and drop. Announce a route into the global system to each
available network with priority set based on the node's best estimate
of the network's bandwidth, likely future availablilty, etc. Cancel
the announcement for any network that has left or is leaving range.
Modify the announcement priority as the node's estimate of the network
evolves.

This is quite impossible with today's BGP core. The update rate would
crush the core, as would the prefix count. And if those problems were
magically solved, BGP still isn't capable of propagating a change fast
enough to be useful for mobile applications.

But suppose you had a TCP protocol that wasn't statically bound to the
IP address by the application layer. Suppose each side of the
connection referenced each other by name, TCP expected to spread
packets across multiple local and remote addresses, and suppose TCP,
down at layer 4, expected to generate calls to the DNS any time it
wasn't sure what addresses it should be talking to.

DNS servers can withstand the update rate. And the prefix count is
moot. DNS is a distributed database. It *already* easily withstands
hundreds of millions of entries in the in-addr.arpa zone alone. And if
the node gets even moderately good at predicting when it will lose
availability for each network it connects to and/or when to ask the
DNS again instead of continuing to try the known IP addresses you can
get to where network drops are ordinarily lossless and only
occasionally result in a few packet losses over the course of a a
single-digit number of seconds.

Which would be just dandy for mobile IP applications.


> The only end to end way to handle multiple addresses is to let
> applications handle them explicitly.

For connection-oriented protocols, that's nonsense. Pick an
appropriate mapping function and you can handle multiple layer 3
addresses just fine at layer 4. Just like we successfully handle layer
2 addresses at layer 3.

For connectionless protocols, maybe. Certainly layer 7 knowledge is
needed to decide whether each path is operational. However, I'm not
convinced that can't be reliably accomplished with a hinting process
where the application tells layer 4 its best guess of which send()'s
succeeded or failed and lets layer 4 figure out the resulting gory
details of address selection.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004




More information about the NANOG mailing list