Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

> - tunnels are a Bad Thing: they waste bandwidth,

Don't host solutions waste b/w discovering alternate addresses? I
think they waste even more than tunnels which are only used when routing
reliably knows there are failures.

> hide the network topology

Tunnels, at least as I used them in my draft
(draft-ramki-multi6-nlmp-00.txt)  don't have to hide topology
in any way. They only mask failures.
Perhaps tunnels is a bad name; may be encapsulation is more appropriate.

>   and current PMTU discovery standards

Current PMTU standard *requires* the host to cope with changes in MTU when
routing changes MTU even with no tunnels. If one is so insistent on not
adding encapsulated header, a router can rewrite the destination routing
goop instead of adding an encapsulation header.

> and implementations easily break in
>   the presence of careless tunnel deployment

My draft shows how you can automate them as attributes to routing; no
manual configuration is necessary.

>
> When the IP layer decides that the destination address is unreachable

how can this be done without wasting b/w?

> performance is not what it should be (because it receives an ICMP
> unreachable,

How do you deal with fake ICMP messages?

> There is a security problem: a host may think it's communicating with host
> with a certain IP address, while it is in fact communicating with a very
> different host, which is not the owner of the IP address in question nor
> reachable over it using regular routing. This breaks "security by looking
> at the IP address", but this was never very secure to begin with anyway.

Arbitrary change of addresses opens up lots of *new* "interesting"
hijacking and DoS issues without a proper security architecture in place.
Something along the lines of hip (host-identity payload) must be used.

One other complexity in doing host-level multihoming is supporting
multicast.

regards,
-ramki