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

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

On 14-apr-2006, at 2:31, Geoff Huston wrote:

> Personally, considering the critical consideration of scaling the  
> IPv6 technology to meet the needs of a truly massively populated  
> network in the fullness of time, I feel entirely comfortable in  
> seeing us work on this scaling issue using a number of approaches  
> at this point in time. Therefore I'm of the personal view that a  
> call to stop working on SHIM6 is somewhat ill-advised right now.

In that case the IESG should speak out against this ARIN policy. The  
ARIN decision makers should know that by doing this, they're shooting  
themselves in the foot (not to mention people outside ARIN region,  
once again I object to the fact that these policies are decided on  
regionally while the implications are global). Saying "oh well  
address policy isn't our purview" isn't good enough when it so  
clearly impacts IETF work.

The problem is that deploying shim6 won't be without challenges. If  
some people can get PI, those will have little incentive to deploy  
shim6. If they subsequently don't others that they communicate with  
don't get multihoming benefits. People who are slightly smaller will  
put effort into getting PI space too which will take away from shim6  
deployment efforts.

And the fact that they're talking about /48s shows that these people  
are fundamentally incapable of learning from the past. I direct your  
attention to this snippet of IPv4 BGP table:

*  12.236.120.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.128.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.136.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.144.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.152.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.160.0/21  4.68.0.243               0             0 3356  
7018 6478 i
*  12.236.168.0/21  4.68.0.243               0             0 3356  
7018 6478 i

Giving people adjacent blocks so that they can "grow" a single  
announcement, in very many cases they don't do this and inject each  
sub-prefix in the global routing table as a separate prefix anyway.  
So giving out /48s while reserving /44s is just plain dumb, as the  
remaining part of the /44 is never going to be allocated to anyone  
else anyway but now people are more or less forced to accept the /48s  
(believe me I'm tempted to filter them out!) even in cases where the  
prefix given out is shorter.