North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: shim6 @ NANOG (forwarded note from John Payne)

  • From: Kevin Day
  • Date: Thu Mar 02 00:18:20 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/ redundancy
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 towards it.

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. :)

-- Kevin