shim6 @ NANOG (forwarded note from John Payne)
toasty at dragondata.com
Thu Mar 2 05:16:26 UTC 2006
For those watching and grumbling, I'll move the discussion to a shim6
mailing list, or in private if anyone wants to continue beyond this.
Just make sure you cc: me if you move the discussion somewhere else.
On Mar 1, 2006, at 12:55 PM, Joe Abley wrote:
> On 1-Mar-2006, at 13:32, Kevin Day wrote:
>>>> We have peering arrangements with about 120 ASNs. How do we mix
>>>> BGP IPv6 peering and Shim6 for transit?
>>> You advertise all your PA netblocks to all your peers.
> If a client has a set of locators, some of which are reachable via
> peering connections and some of which are reachable via transit
> connections, you want to be able to bias the locator selection such
> that (perhaps, e.g.) peering locators are always preferred to those
> which involve transit providers.
> Although simple performance benefits might cause hosts to make that
> decision on their own, you don't want to leave the decision up to
> the hosts, since if they get it wrong it will cost you money.
> This seems inordinately reasonable. Did I summarise correctly?
For the most part, yes. The information of "who is a peer" is only
received into our network via BGP. There needs to be a near realtime
interface between BGP on N routers, being made available to influence
shim6 decisions on X hosts. A quick look at our peering sessions now
shows about 20,000 peer routes. I'm a bit worried that I need to send
20,000+ pieces of routing information to hundreds/thousands of hosts,
if I want them to make decisions based on that.
>> Without totally upending my network, I need:
>> 1) PI space
>> 2) The ability to deaggregate that PI space where truly needed.
>> (or the ability to request multiple PI blocks, but I don't see how
>> that helps matters)
>> 3) BGP announcements to the world
> For sure, the simplest and cheapest thing for you would be to
> obtain PI space and continue as you have been doing with v4. The
> implications of that are not necessarily simple nor cheap for
> others, however, if you're one of $BIGNUM people doing it.
No, I'm just trying to be practical here... Estimates of IPv4 pool
exhaustion range from Mid 2008 (Tony Hain's ARIN presentation) to
roughly 2012 (Geoff Huston's ARIN presentation). Sooner if a mad dash
for space starts happening (or isn't happening already).
Does anyone here really believe that there is time for:
1) Getting shim6 from proposal to standard
2) Develop reference implementations to prove that it works, and base
other development on
3) Convincing OS/Router/other vendors that shim6 is practical and
needed, and the best of all ipv6 multihoming solutions
4) Having every major OS/Router/other vendor plan, develop and
release software that supports shim6
5) Allow time for application, firewall and other vendors to release
upgrades to support shim6 features that may be necessary
6) Developing any "middleware" applications as discussed earlier, on
top of adding basic shim6 support
7) Having ISPs/Hosting companies/Enterprises/End users to upgrade all
critical and legacy systems to shim6 compatible software
8) Allowing for ISPs/Hosting companies to convince all their
customers to upgrade the servers that are outside of the ISP's
control (owned by the customers), or deal with losing reliability/
8a) In a way that doesn't encourage customers to just move to a
hosting provider that has PI space and doesn't need to deal with shim6.
9) Replacing hardware or software that was designed to be ipv6
compatible, but cannot be upgraded to a shim6 stack. (Vendor out of
business, vendor won't produce upgrade, etc)
10) The learning curve for network engineers to learn a whole new way
of traffic engineering
PLUS the existing resistance/foot-dragging about just implementing
IPv6 as it is? Far enough in advance of IPv4 exhaustion that IPv6 is
a stable and established platform, with a critical mass of ISPs, NSPs
content companies and end users on it?
All of the above need to happen before PA holders can realistically
switch to IPv6 using Shim6. I can't see Shim6 being ready and
deployable until well after we already need to have a large
percentage of the world using IPv6.
My argument isn't that Shim6 will never work for anyone, or that it
couldn't be made to work for us EVENTUALLY. I'm saying the pain level
of transitioning to IPv6 is too high for any multihoming PA-holding
company to willingly do it until they're forced to. The world won't
end if we separate "transition to IPv6 addressing" and "transition to
more scalable routing/allocation policies" into to different battles,
that each need to be won on their own merits. Win the war of just
getting people to use IPv6 addressing alone, then when reasonable
alternatives to multihoming are ready and usable, let those who can
use them transition on their own.
I realize pool exhaustion != death of IPv4, but it's a big step
As an aside, for those thinking I'm arguing out of self-interest...
We have a /32, none of this discussion is to save me any work or
headache. I'm not sure if that helps or hurts my credibility or
perceived intentions though. :)
More information about the NANOG