Re: Shim6, was: Re: filtering /48 is going to be necessary

[Owen DeLong <owen () delong com>]

On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote:

> On 11 Mar 2012, at 20:15 , Joel jaeggli wrote:
>
> > > The IETF and IRTF have looked at the routing scalability issue for a
> > > long time. The IETF came up with shim6, which allows multihoming
> > > without BGP. Unfortunately, ARIN started to allow IPv6 PI just in
> > > time so nobody bothered to adopt shim6.
>
> > That's a fairly simplistic version of why shim6 failed. A better reason
> > (appart from the fact the building an upper layer overlay of the whole
> > internet on an ip protocol that's largely unedeployed was hard) is that
> > it leaves the destination unable to perform traffic engineering.
>
> I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it 
> requires support on both sides of a communication session/association.
>
> But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI 
> after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to 
> judge whether it would be good enough.

As the person who led the charge in that action, I can probably answer that question...

First, from my perspective at the time, SHIM6 didn't stand a chance. It was massively complex, required modifying the 
stack on every single end system to yield useful results and mad windows domain administration look simple by 
comparison.

As such, I just didn't see any probability of SHIM6 becoming operational reality. (I think LISP suffers from many, 
though not all) of the same problems, frankly.

I remember having this argument with you at the time, so, I'm surprised you don't remember the other side of the 
argument from the original discussions.

However, there was also tremendous pressure in the community for "We're not going to adopt IPv6 when it puts us at a 
competitive disadvantage by locking us in to our upstream choices while we have portability with IPv4."

Like it or not, that's a reality and it's a reality that is critically important to getting IPv6 adopted on a wider 
scale. Fortunately, it was a reality we were able to address through policy (though not without significant opposition 
from purists like yourself and larger providers that like the idea of locking in customers).

> > That fundementaly is the business we're in when advertising prefixes to more
> > than one provider, ingress path selection.
>
> That's the business network operators are in. That's not the business end users who don't want to depend on a single 
> ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion 
> "basement multihomers" with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective 
> of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes 
> mainstream.

It's not just about depending on a single ISP, it's also about being able to change your mind about which ISPs you are 
attached to without having to undertake a multi-month corporate-wide project in the process.

Let's compare...

BGP multihoming with portable PI prefix:
        1.      Sign new contract.
        2.      Make new connection.
        3.      Bring up new BGP session.
        4.      Verify routes are working in both directions and seen globally.
        5.      --
        6.      --
        7.      --
        8.      --
        9.      Tear down old BGP session.
        10.     --
        11.     Terminate old contract.
        12.     --

PA based prefix:
        1.      Sign new contract.
        2.      Make new connection.
        3.      Get routing working for new prefix over new connection.
        4.      Add new prefix to all routers, switches, provisioning systems, databases, etc.
        5.      Renumber every machine in the company.
        6.      Renumber all of the VPNs.
        7.      Deal with all the remote ACL issues.
        8.      Deal with any other fallout.
        9.      Turn off old prefix and connection.
        10.     Deal with the fallout from the things that weren't symptomatic in steps 4-9.
        11.  Terminate old contract
        12.     Remove old prefix from all remaining equipment configurations.

By my count, that's twice as many steps to move a PA end-user organization and let's face it, steps 5, 6, and 7 (which 
don't exist in the PI scenario) take the longest and steps 7, 8, and 10 (again, non-existant in the PI scenario) are 
the most painful and potentially the most costly.

No multihomed business in their right mind is going to accept PA space as a viable way to run their network.

Owen