shim6 @ NANOG (forwarded note from John Payne)

Iljitsch van Beijnum iljitsch at
Tue Feb 28 19:22:04 UTC 2006

On 28-feb-2006, at 17:09, Kevin Day wrote:

> Some problems/issues that are solved by current IPv4 TE practices  
> that we are currently using, that we can't do easily in Shim6:

Well, you can't do anything with shim6 because it doesn't exist yet.  
That's the good part: if you speak up now, you can get capabilities  
added before the spec is finished.

> 1) Prepending/tagging routes to influence the amount of inbound we  
> receive from certain providers

Should be doable with a DNS SRV record like mechanism. Don't worry  
too much about this one.

> 2) Announcing more specifics to some peers/transit to influence  
> which POP certain traffic is received

Actually you could still do that with shim6: whatever happens between  
you and your ISP is your business and doesn't inflate the global  
routing table. In practice, you'd probably have different /48 blocks  
for different POPs to begin with so for stuff where you can  
differentiate on destination address, you can very easily get the  
traffic to the place where you want it to be.

> 3) Announcing less specifics (total aggregate announcement) to  
> "backup" transit provider/connections that we don't want to receive  
> traffic on unless something is really really wrong

This is something that is incompatible with shim6. So if we want to  
retain this functionality, we have to go back to what you're really  
trying to do and then come up with a new, shim6-compatible way of  
doing it.

> 4) Being able to do 1-3 in realtime, in one place, without waiting  
> for DNS caching or connections to expire

How fast is real time?

And are we just talking about changing preferences here, or about  
what happens when there are outages?

> 5) Being able to make routing/policy changes without having to rely  
> on the owners/administrators of the machines/sites/domains  
> themselves to do the right thing. (i.e. untrusted/not-maintained-by- 
> us systems/networks on our network)

If you're a multihomed hosting company you would want to do TE for  
your entire POP, but you wouldn't necessarily be able to change  
information in the DNS for all the hosts/services that your customers  
run. Is that what you mean?

> 6) Anycast?

I don't think shim6 applies to interdomain anycast. (Which is a hack  

> 7) During what will be a very lengthy dual-stack transitional  
> period, having to do TE in two entirely different ways. BGP 
> +Prepending+Selective-announcements along side Shim6 doesn't really  
> sound like fun to me. We can't treat bits as bits, we have to  
> consider if they're IPv4 bits or IPv6 bits, and engineer them  
> differently, even though they're sharing the same lines and are  
> probably going to have a 1:1 addressing relationship between IPv4  
> and IPv6 services.


This is a result of the transition to IPv6, regardless of shim6.

> On top of those, even if shim6 accomplishes the failover and  
> reliability goals, I can't see how shim6 is going to make path  
> decisions as optimal as IPv4/BGP/etc.

Really??? The way I see it, BGP decisions today are mediocre at best.  
If anything, I would expect things to get better with shim6.

> My last IPv6 experiment proved that if we're going to provide IPv6,  
> it has to be as fast to the end user as IPv4 is, or users will  
> switch off their IPv6 stack entirely. If an end user is running a  
> dual stack system, sees slow performance a non-optimal path being  
> chosen via shim6, they'll turn IPv6 off so they can reach the IPv4  
> version of the site. Anything we do has to ensure that IPv6 has AT  
> LEAST the same visible performance to the end user, or they're not  
> going to be willing switchers.

Tell it to the people who still do IPv6 routing the way they did in  
1999... It's not much fun to go from one part of Europe to another  
through Japan. Fortunately, this is getting better all the time, but  
we're not there yet. But also orthogonal to IPv6.

More information about the NANOG mailing list