On Wed, Nov 07, 2001 at 09:28:26PM -0800, Bill Manning wrote:
% >Actually, the engineering cost of building IPv6 into operating systems
% >is already essentially paid. The cost of building it into routers and the
% >like
% >is paid. The vendors are all (basically) IPv6-ready.
%
% Valdis,
%
% Your message is generally well put. However, while it is possible to send
% the packets on the wire, the fundamental underlying scaling point, the
% routing system, has not been properly addressed. Perhaps a solution can be
% retrofitted in, but then again, who knows? This, I thought, was <largely>
% the point of multi6.
%
% Eliot
Hum... I thought that multi6 was trying to figure out the ramifications
of multihomeing w/ IPv6. The issues wrt the routing system really
need to occur in a WG devoted to better routing protocols, not one
with a focus on multihoming. at least IMHO...
multi6 is trying to agree on a strategy for multi-homing in IPv6
that meets a set of requirements. Amongst those requirements (in
the current, outdated draft, which we are hurrying to improve) is
this:
3.2 Additional Requirements
3.2.1 Scalability
Current IPV4 multihoming practices contribute to the significant
growth currently observed in the state held in the global inter-
provider routing system; this is a concern both because of the
hardware requirements it imposes and also because of the impact on
the stability of the routing system. This issue is discussed in
great detail in [9].
A new IPv6 multihoming architecture should scale to accommodate
orders of magnitude more multi-homed enterprises without imposing
unreasonable requirements on the routing system.
Hence, we hope to identify a solution which scales better than the
hole-punching antics common in IPv4.
So, Bill is right; scaling the routing system is not in the list
of objectives in multi6. However, if we find a good solution to
multihoming, we may be able to eliminate a big contributor to the
amount of state held in the routing system, and in that way reduce
the urgency of finding a scaling solution.
Joe