IPv6 multihoming question

Hank Nussbacher hank at efes.iucc.ac.il
Mon Apr 17 20:37:15 CEST 2006

On Mon, 17 Apr 2006, Steve Powell wrote:

Worth reading:

RFC4218 - Threats Relating to IPv6 Multihoming Solutions, Nov 2005


> Greetings.  The multihome addressing issue for IPv6 is definitly
> interesting and I sympasize with the idealists who would like
> to see nice neat, clean routing tables.  Then again everything I
> have always had an idea for started neat and clean.  Before I
> knew it, lifes one thousand exceptions had blown it up into
> a monster, and they come shambling out of the garage to eat me. ;)
> In my opinion the issue boils down to a statistical mechanics
> problem.  If additional information is to be transmited(multihomed
> customer), then additional "state" is required to support the
> transmission of that information.  Regardless if you use the Ipv4
> solution, the shim draft, DNS, or even build  the mechanisim in
> the client/server, something must carry the additional information
> and make decisions.  The superior solution will carry the most
> information and generate the least amount of entropy.
> The IPv4 world likes big messy routing tables because ultimately
> this centralized model carries the most information for the least
> amount of entropy, which is a byproduct of state.  Previous
> submiters have pointed out that router vendors are building more
> capable devices that are able to easily handle projected route
> table growth.
> The IPv4 world is very happy with how IPv4 works along with their
> ethernet.  The IPv4 world will not convert to IPv6 unless the IPv4
> world observes the same luxuries available in IPv6.  If we wish
> to turn the world upside down, we have to show a compelling
> reason for doing it.  Since big routing tables is an issue easily
> handled by the IPv4 world, arguments for doing multihoming differently
> are not going to sway it.
> stevep
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.

More information about the ipv6-ops mailing list