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
Attachment:
pgpgAEQdqB8OF.pgp
Description: PGP signature