[ppml] question on 2006-2 v6 internal microallocation

[Pekka Savola]

On Wed, 23 Aug 2006, Jason Schiller wrote:
> But that still leaves part of the question unanswered.  Is it worth noting
> that the intent is that this micro-allocation for critical infrastructure
> is not intended to be advertised to the global routing table (without
> trying to set routing policy)?
...
> Just wondering if people find value in that as part of the policy, or is
> clearly understood?

I think putting it in terms of 'advertised' is a bit backwards. 
Rather, you should ask something like:

   Do packets legitimately including a source address from this address
   block ever get sent over the public Internet?  (YES/NO)

I'm not sure if I'd want to see internal, non-routed infrastructure 
blocks being used to send packets (e.g., traceroute responses) which 
cannot be dropped by uRPF and other ingress filtering mechanisms.

That aside...

I looked at the policy proposal, and the BGP re-convergence rationale 
seems to be quite odd or outdated.  This is exactly the reason why 
e.g., JunOS supports 'routing-options - resolution - rib FOO - import' 
configuration.  We've used that ourselves for years now and there is 
no issue with numbering the BGP sessions from the aggregate.  I'd 
suspect Cisco supports similar configuration, or would easily to be 
fixed to do so.

Internal structure considerations also doesn't apply, as your 
neighbors and customers can static-route to your internal block unless 
you implement packet filtering at your borders.  Hence, I cannot see a 
scenario where packet filtering wouldn't be sufficient.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings