[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Re: Fast and sparse mapping?
On 22 sep 2008, at 17:02, Marshall Eubanks wrote:
If the space is densely populated you can simply use an array, this
is extemely efficient.
Is there any actual chance of having a densely populated space in
IPv6 ?
Not for the whole space, of course. But you could have parts of it
densely packed and the same prefix length, so you could have a bunch
of arrays... But then you need to have a two step lookup algorithm.
On 22 sep 2008, at 17:25, Stephen Sprunk wrote:
Currently the RIRs are being extra sparse on purpose (reserving a /
44 for everyone who gets a /48) and I've long argued that this
doesn't have the intended helpful effect in practice but it is
harmful because of the increased sparseness.
The RIRs were told by operators that limiting the total number of
routes (by allowing room for growth thus removing the need for most
orgs to come back for additional blocks) was more important than
keeping the space densely populated.
Unfortunately, it doesn't seem to work much in practice because very
many people simply advertise a bunch of /20s rather than something
bigger. The move from /35 to /32 in IPv6 took forever and I'm willing
to bet there are still some /35s out there.
We are barely at the point where routers could theoretically handle
a densely-populated 32-bit route table, years away from being able
to handle a densely-populated 48-bit route table, and pushing either
through BGP-4 is patently impossible. So, I tend to think the
operators had it right.
The problem is that if you have 64k /48s that would be a /32, but they
actually reserve a /44 for each of those /48 users so they use up a /
28. Now if you aggregate that /28 into /48s (and most of the prefixes
in that /28 are /48s) then you end up with 1M /48s which will
instantly kill any existing router and there is no filter that allows
the actually assigned prefixes but doesn't allow this type of
deaggregation. With a /32 worth of /48s this risk is much reduced.
People who need more space can then get a /44 or whatever they need as
a second block. Yes, this means two blocks instead of one (probably
infeasible to make them return the original /48) but we're at more
than 8 prefixes AVERAGE for IPv4 today so 2 in SOME cases isn't so bad
if this makes it possible to filter against deaggregation attacks.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg