Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]

["Per Heldal" <heldal@eml.cc>]

On Thu, 13 Apr 2006 23:58:27 +0200, "Iljitsch van Beijnum"
<iljitsch@muada.com> said:
> Now obviously the IESG has in the past felt that multi6 and shim6  
> work was valuable. Although fewer people qualify under this policy  
> (you need to qualify for an IPv4 block and the smallest ones that  
> ARIN gives out are /20s so few people do, AFAIK) than would be able  
> to use shim6, I think it's safe to say that with policies like this  
> in place shim6 will be dead in the water. Pursuing both seems a big  
> waste of time. So I suggest that the IESG either:
> 
> 1. Tells ARIN that this policy is incompatible with work inside the  
> IETF so it shouldn't be adopted, or
> 
> 2. Conclude shim6.

That is awfully narrow-minded. The new policy indicate that V6-adoption
is growing, and that it is time for operational policies to reflect
real-life. Multihoming with BGP works fine today, while shim6 is
vapor-ware.
We wouldn't have this discussion if shim6 had been available today with
all
the necessary supporting technologies and products for it to be widely
accepted as the superior solution .

How can you expect operational policies to be based on technology that
doesn't yet exist (feed the starving from next years crops)? From a
non-technical perspective, can you somehow
eliminate redundant connectivity and provider independence from people's
list of business-requirements? 

OTOH, this is in no way the end of shim6. The new policy is,
as you say, restricted to a limited number of sites. Besides, what about
potential advantages to the
shim approach? Its not entirely impossible that it could be developed
into something with appeal even to large networks sometime in the
future.

An alternative policy would be to make these PI
assignments temporary. When alternative technology is available,
PI-sites could be asked to move to alternative solutions within X-years
or so. I do however not see how PI-assignments can be avoided
altogether as there is no viable technical alternative.

//per
-- 
  Per Heldal
  http://heldal.eml.cc/