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