On Mon, 10 Oct 2005, Brian E Carpenter wrote: > Date: Mon, 10 Oct 2005 14:17:11 +0200 > From: Brian E Carpenter <[EMAIL PROTECTED]> > To: Mohacsi Janos <[EMAIL PROTECTED]> > Cc: John Payne <[EMAIL PROTECTED]>, > Iljitsch van Beijnum <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > David Meyer <[EMAIL PROTECTED]>, [email protected], [EMAIL PROTECTED] > Subject: Re: IPv6 Multi-homing BOF at NANOG 35 > > Mohacsi Janos wrote: > > Dear all, > > > > On Tue, 4 Oct 2005, John Payne wrote: > > > > > > I think most of the ISP who are seriously thinking about IPv6 have to > > have the ability to have a multihoming solution - getting PI-like > > address (nowadays it is /32).
Some ISPs can get their own aggregate, some are too small and can't. Even having your own aggregate in the global routing table and doing IPv4 style multi-homing doesn't provide you with all of the tools you currently have in IPv4 multi-homing. Distancing all the customers of a given provider is not quite as useful as distancing one customer prefix behind one provider. Having commercial customers who require multi-homing but can't get their own prefix in the global routing table is a barrier to entry, and impacts ISPs who have many such customers. Commercial customers with their own prefix in the global routing table and doing IPv4 style multi-homing doesn't provide them with all of the tools they currently have in IPv4 multi-homing. If they are only allowed to advertise a single aggregate, they can split load across multiple transit providers. > > The point of shim6 is to *avoid* the need for PI-like space > for multihomed sites, so that we don't do to the IPv6 BGP table > what multihoming is doing to the IPv4 BGP table. We need IPv6 > to scale vastly more than IPv4, so this is essential. Yes. We can put all of the IPv6 more specifics into the global routing table, but current hardware won't scale to hold that. Its not clear that the technology to hold the larger RIB and FIB will be available in 5 years, or if it will be cost prohibitive. If we try to solve this in some other way then de-aggregation, then we need to make sure it is at least as functional and easy to operate as what we have now, or no operators will want to adopt it. > > I hope the proposed BOF will make this clearer. I personally > think that shim6 will be really cool for ISPs, although as Geoff > says it will take a while to deploy and during that time we'll > need a PI-like approach. > > Brian There are many content providers who are avoiding IPv6 as they beleive it is not yet ready for "prime time" commerical traffic as it lacks sufficent multi-homing capabilities. Clearly we need a multi-homing solution now. However I am concerned that if we allow PI addresses into the global routing table, then we begin down the path of solving the multi-homing problem by de-aggregating. In 10 years time, there may be many de-aggregates in the global routing table. At that time it will be much harder to tighten the belt and get those prefixes out of the global routing table. Do you think that operators of commercial networks will want to switch to shim6? Consider the current comfort level with the IPv4 style BGP de-aggregate traffic engineering. Consider that the current approach to shim6 is less functional than the current IPv4 style multi-homing. Consider the the shim6 solution may be very different to operate (configuring end hosts instead of Internet facing routers) and may break current operational boundaries. Shim6 as a host multi-homing solution lends itself nicely to consumer networks all operated by few end users with few hosts, but is more problematic to implement it in a large commerical network. Don't miss read me. I'm not bashing shim6. I'm suggesting it needs to be as functional as what operators currently have. I'm also suggesting that there is a barrier to change, and if traditional IPv4 style multi-homing is allowed to be done in IPv6 then comercial networks may never adopt a shim6 solution. ARIN is currently considerig PI IPv6 space. See Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites: http://www.arin.net/policy/proposals/2005_1.html It is my belief that if this policy goes through that commercial sites will be unlikely adopt a shim6 solution. ___Jason > > > > For end-systems/customers/enterprises > > might agree with upstream providers to accept more specific (and > > upstream can agree to exchange more specific inside country/region, but > > announce aggregate to global Internet) or use RFC3178 method (using > > tunnels) which is quite powerful technique. Any method can be > > implemented with careful BGP routing policy configuration. > > The shim6 is attractive method, but requires changes in host and router > > IPv6 implementations and this requires at least 5 years to be widely > > accepted.... > > > > Shim6 can be a long term solution, but shorter time-frame the > > operator/provider/user community can use existing methods to support/use > > multihoming. We can strart using it and if there is some problem we can > > speak up at NANOG/RIR etc meetings. > > > > > > Regards, > > > > > > Janos Mohacsi > > Network Engineer, Research Associate > > NIIF/HUNGARNET, HUNGARY > > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > > > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
