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