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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 27-feb-2006, at 15:12, Per Heldal wrote:

> I share most of your views, but you are missing an important point:
> Frustration in the ops-community stems from inconsistency between
> operational policies and technical capabilities.

> Consider:

> * Current V4 multihomers (content providers in particular) are not
> willing to adopt V6 without a MH-solution.

> * RIRs currently don't support MH for v6 endsites.

> * shim6 is currently the only technical initiative to bring MH to  
> V6. It
> is therefore expected to bring any and all MH and TM-related
> functionality from day 1 (even far beyond just what's possible with
> BGP-tweaks).  That is about as realistic as expecting to find
> features related to stateful inspection of packet-streams in modern
> products (firewalls, load-balancers etc) explicitly described in the
> original TCP-specification.

Necessity is the mother of invention...

> In 5 or 10 years,

Any time someone mentions timelines like this that indicates to me an  
incomplete understanding of the problem. Everything we understand  
today can happen in less than 5 years.

> when supporting tools are in place for (near-)
> immediate renumbering or to add/remove prefixes to/from sites of *any*
> size including directory (DNS .. whatever) updates, and with tools to
> manage/coordinate traffic on any number of shim6-capable boxes  
> within a
> site this will no longer be an issue.

Unfortunately, it's becoming quite clear that IETF efforts to allow  
for rapid renumbering have dead ended. Renumbering itself is very  
easy and nearly 100% transparent to applications and the user in  
IPv6. Unfortunately, when hosts get different addresses some other  
stuff must change as well:

- ingress filtering/egress selection
- DNS records
- anything that has IP addresses hardcoded in general

And worse, all of this has to happen at pretty much the same time to  
be effective. In order to be able to do this, many things that are  
strict today must become more relaxed or the other way around, and  
operators simply don't seem to want it. (It would help if we could  
retire the whole filtering/firewalling security model that exists  
today.)

> In the meantime, if we want to give shim6 (or alternatives) time to
> evolve there are 2 options.

> - Openly and wholehartedly discourage v6 deployment for purposes where
> global reachability is expected till the technology is complete.

Looking at current IPv6 adoption it seems that discouragement isn't  
required.  :-)

>  . or .

> - Work with the RIRs, possibly with recommendations through IANA, to
> implement routing-policies for v6 which will work with existing
> technology.

Unfortunately the RIR constituency seems to be incapable of anything  
more productive than whine that they want PI in IPv6 just like it  
exists in IPv4.

If anyone is interested in exploring this seriously, which to me  
means finding new ways to aggregate that were summarily rejected in  
the past, I'm all for that.