shim6 @ NANOG (forwarded note from John Payne)

Kevin Day 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/ 
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





More information about the NANOG mailing list