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

Tue Mar 13 07:21:17 UTC 2012

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.

Your estimate on the number of routers in DFZ:

	somewhere between 120,000 and 180,000 with the consensus
	number near 150,000

is a result of high cost of routers and is inappropriate to
estimate global cost of a routing table entry.

Because DFZ capable routers are so expensive, the actual
number of routers is so limited.

If the number of routes in DFZ is, say, 100, many routers and
hosts will be default free.

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

My statement is based on my experience to implement locator/ID
separation system with multi-address TCP and IP mobility.

They need separate mechanisms and separate coding.

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

That is a mobility issue of triangle elimination having nothing
to do with TCP.

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

Ignoring that DNS does not work so fast, TCP becomes "it wasn't
sure what addresses it should be talking to" only after a long
timeout.

> 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

What? A node asks DNS IP addresses of its peer, because the node
is changing its IP addresses?

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

It will require the applications perform reverse mapping
function, when they require raw IP addresses.

> For connectionless protocols, maybe.

I'm afraid you are unaware of connected UDP.

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

That's annoying, which is partly why shim6 failed.

It's a lot easier for UDP-based applications directly manage
multiple IP addresses.

						Masataka Ohta