BCP for multisite multihoming

[Gert Doering]

Hi,

On Wed, May 23, 2007 at 11:55:13AM +0200, Iljitsch van Beijnum wrote:
> >[OK, come flame me.  *I* can do maths.  Can you?]).
> Ok, I can't resist that one...
[..]
> Obviously, the IPv6 address space can stand to lose a few /32s here  
> and there, as there are 536 million of them available. But a year  
[..]
> routing, but considering that there are 1.4 million businesses in the  
> Netherlands alone, I'm thinking we can screw this up if we try hard  
> enough and take enough time to do it.

You missed my point.  My point wasn't "we can afford to give anyone
that comes a /32" - it was "for the number of routes that we can afford,
it doesn't make a (big) difference whether it's a /32 or a /40, because 
this is not going to use up all the available space anyway".

Indeed we can *not* affort "a globally visible route for every 'business'
in the world".

[..]
> Since we obviously can't depend on the address space holders to do  
> the right thing, it's necessary to filter. A good filter catches  
> everything that's in the routing table by mistake, and allows  
> everything that's in there by design. Unfortunately, today's policies  
> and practice don't make this very easy, for two reasons:

A *good* filter is one that permits exactly what is supposed to be there
(as documented in a routing registry) and nothing else.  This is perfectly
well doable towards customers, and mostly doable towards peers.

Heuristics only work, well, by chance.

> 1. PA assignments are (often) /48s, same thing for PI blocks, so it's  
> not possible to see the difference between leaked PA deaggregates and PI

Indeed it is, as the RIRs take good care to set aside specific blocks
for special-case prefixes (PI, IXP, ...).  It's a bit time-consuming to
always figure out which block is what, but it can be done.

> 2. /32 and larger allocations are made from the same bunches of  
> address space. This means that someone with a /21 can inject 2048 / 
> 32s. However, due to the HD ratio, people can get a /21 if they need  
> around 450 /32s. So giving out larger blocks to aid aggregation can  
> actually make deaggregation worse.

Indeed.  If one assumes that those enterprise have nothing better to
do than to deaggregate to /32s.

> Fixes:
> 
> 1. Make PI blocks a different size than PA end-user assignments. /44  
> makes sense, this is a good deal bigger than /48 so even fewer people  
> are going to need more and it's on a nibble boundary for easy DNS  
> delegation and no need to reserve for growth. Filtering could happen  
> on /47 which rejects leaked /48s but allows 3 bits for traffic  
> engineering

See my comment to "1." above - this is a solution in search of a problem :-)

Doing this has another drawback: it makes PI more attractive to end sites
than PA ("I can get a bigger address block with PI!!!") - which is not
what we should aim for.

(We already have this, with the new approach "end users can get anything
between /64 and /48", but as the policies still permit /48s to be given
out to end sites "no questions asked", it's not that bad yet)

> 2. Make all allocations from a given block of address space the same  
> size, so there would be ranges for /32s allocations, for /28  
> allocations, /44 assignments, etc.

Given the sheer and overwhelming amount of bigger-than-/32 allocations,
filtering these ranges explicitely is not a seriously big deal.

> >Regarding routing table: it doesn't make a difference what you do
> >("own /32, deaggregated single /32, PI networks") - with current
> >routing technology, you end up with one routing table slot per  
> >location.
> >Which is not perfect, but as long as it stays at *one* prefix per
> >location,
> 
> Oh, now we're doing a PI block per location? I'm guessing a PI block  
> per plane is next, then one per car, one per mobile phone... After  
> all, I don't want to have to renumber when I take my laptop from home  
> to work.

I was responding in a very specific context.  If you don't want to consider
my comments *in the context of the given question*, then please don't 
bother answering to them at all.

I explictely wrote "in the current policy and routing framework" as 
a preface to this answer - and there is no other answer.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070523/d7c8a868/attachment.sig>