oh silly me, I skipped over 'hostroute' and read 'class c' doh 
anyway,
this all seems foolish in the end, making the same mistakes again is going
to bite someone in the behind.
>>> class C == /56
>>> hostroute == /64and i:
as, in the truely classful days, a lan was a C == /24, i'll
stick to my guns for the moment that a new C is a /64 and so
forth.
and this from the man who actually received a /33 delegation
in v4 space! 
as there is no emoticon for sarcasm, the naive should know
that i (and maybe bill) draw this comparison to point out
that, by codifying such boundaries in technology and policy,
we're making the same old mistakes again.
amen... in spades.
--bill
Because the thinking at the time appears to be that to "ease' renumbering reduce the costs associated with address distribution functions (and associated network assessment tasks) and because there were heaps of addresses, all end-sites would get the same address allocation, and the uniform amount that was arrived at was a /48 . When asked whether this referred to _everything_ that may require subnets, the answer was "yes". When asked whether this encompassed everything from a mobile phone to a large corporate the answer given was, once more, "yes".
Why /48 rather than /47 or /49? - alignment to nibble boundaries to make DNS delegation easier.
Why /48 rather than /32 or /40? I really cannot say - I suspect that /48 is the largest end site number that meets the projected scope as described in RFC 3177.
regards,
Geoff
It's quite arbitrary though, unlike the old classful IPv4 divisions - a matter of policy, not technology. The allocation sizes can and do vary over both time (as policy changes, IIRC RIPE used to assign /35s iirc, now it's /32) and between different RIRs.
A hostroute is /128 btw. 
regards,
Please pardon the crossposting between ppml and nanog...
Geoff Huston <gih@apnic.net> writes:
Why /48 rather than /47 or /49? - alignment to nibble boundaries to
make DNS delegation easier.
It has recently come to my attention that we are in error when we
expect "n[iy]bble" to have the same amount of popular awareness as
"byte". In point of fact, my guess is that most people who are not
programmers (or particularly assembly language programmers) have
minimal or no exposure to the term. Particularly in public policy
discussions, such people abound, and their engagement in the process
is no less important than that of a protocol implementer.
Future proposals involving a preference toward doing things with 4-bit
alignment should take care to explain what precisely a "n[iy]bble" is
and hexadecimal numbering, and why it matters.
---Rob
Well, they are somewhat special. All of them are on eight-bit boundaries.
The importance of this comes in when deciding how to lay out a routing table
in a gate array or memory-based table.
A routing table capable of handling a flat 2^128 addressing space goes
beyond the realm of known physics -- and flat 2^64 comes close, at least for
a while (consider semiconductor atomic weights, and the fact that 1 mole is
approximately 2^79 atoms). That's quite a stretch, but should give a hint
as to why flat addressing does not work for every model.
Routing tables become much simpler when you have N-level (tree-like) tables,
a concept also used in MMUs. A tree done one bit at a time, while the most
compact form in many cases, is not very efficient at lookups. If you divide
the bitspace into sized chunks, the lookup time can be a better tradeoff
between speed and tree size.
Specifically, 8-bit dividing lines make this even easier. Much logic
programming (FPGA or similar) depends on power-of-two data sizes with a
minimum of 4 or 8 bits. This has led to well established 4-bit and 8-bit
data movement patterns that have been better optimized over time. If using
a store-and-forward mechanism with a more generic data processor (such as a
CPU), 8-bit dividing lines are all the more important for speed.
Or in summary of all of the above, "8-bit building blocks in routing tables
make writing the physical routing code much easier, and in many cases makes
the forwarding operation much faster."
Come on now, a lot of new routing gear made today can just barely handle
2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere
near handling 2^32 routes even for IPv4, nor should we be, so lets not
start the whole "but ipv6 has more space therefore routes will increase to
7873289439872361837492837493874982347932847329874293874" nonsense again.
Removing the extreme restrictions on IP space allocation by being able to
allocate chunks so large that you would RARELY need to go back for a
second block would immediate reduce the size of the routing table. Let me
state the stats again for the record:
Total ASes present in the Internet Routing Table: 20761
Origin-only ASes present in the Internet Routing Table: 18044
Origin ASes announcing only one prefix: 8555
Transit ASes present in the Internet Routing Table: 2717
There are just not that many distinct BGP speaking networks out there, nor
will there ever be. NOW is the time to make certain that IPv6 deployments
makes sense in practice and not just in theory, so we don't work ourselves
into exactly the same mess that we did in IPv4. Lets stop trying to solve
theoretical scaling problems which will never happen at the expense of
creating problems which actually DO exist, and apply a little bit of
common sense.
ack that.
assign one ipv6 prefix to every asn of sufficient size that most will not need
to request additional space
whilst i'm at the mic here, ditch the idea of microassignments, just give out a
standard /32 block ... lets not start out with ge 33 prefixes in the table when
theres no need
Steve
whilst i'm at the mic here, ditch the idea of microassignments, just give out a
standard /32 block ... lets not start out with ge 33 prefixes in the table when
theres no needSteve
there is this wonderful, apparently US phenomeon, called the
"warehouse" store aka Stuffmart. Single guys go in for a quart
of milk and some TP and walk out w/ a MINIMUM of four gallons of
milk, 144 rolls of TP, and a side of beef.
saving the poor routing table is a laudable and worthwhile goal,
but dumping the excess into the edges, "just cause its easy" strikes
me as lame. a routing table slot is a slot is a slot. It holds
a /96 as well as a /32 as well as a /112. If we are going to ditch
"microassignments" (and boy is that term an oxymoron) then we should
also dump "one-size-fits-all" and really and truely give folks what
they need. RIRs have -never- assured the routablity of delegations.
--oat willie (as a lone voice)
Disagree.
The one saving grace I can see of v6 is that there is enough space to give everyone the space they need in a single allocation.
It's not a waste if it keeps people from needing a second block.
Maybe not everyone needs a /32, but let's not get stingy with plentiful resources (IP space in v6) and risk using too much of a not-so-plentiful resource (routing table slot).
> actually, no, I could compare a /48 to a class A.
...which makes the /32s-and-shorter that everybody's actually getting
double-plus-As, or what?
no, super *duper* A's.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A routing table capable of handling a flat 2^128 addressing space goes
beyond the realm of known physics -- and flat 2^64 comes close, at least for
a while (consider semiconductor atomic weights, and the fact that 1 mole is
approximately 2^79 atoms). That's quite a stretch, but should give a hint
as to why flat addressing does not work for every model.Come on now, a lot of new routing gear made today can just barely handle
2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere
near handling 2^32 routes even for IPv4, nor should we be, so lets not
start the whole "but ipv6 has more space therefore routes will increase to
7873289439872361837492837493874982347932847329874293874" nonsense again.
Removing the extreme restrictions on IP space allocation by being able to
allocate chunks so large that you would RARELY need to go back for a
second block would immediate reduce the size of the routing table. Let me
state the stats again for the record:Total ASes present in the Internet Routing Table: 20761
Origin-only ASes present in the Internet Routing Table: 18044
Origin ASes announcing only one prefix: 8555
Transit ASes present in the Internet Routing Table: 2717There are just not that many distinct BGP speaking networks out there, nor
will there ever be. NOW is the time to make certain that IPv6 deployments
makes sense in practice and not just in theory, so we don't work ourselves
into exactly the same mess that we did in IPv4. Lets stop trying to solve
theoretical scaling problems which will never happen at the expense of
creating problems which actually DO exist, and apply a little bit of common
sense.
whilst i'm at the mic here, ditch the idea of microassignments, just give out a
standard /32 block ... lets not start out with ge 33 prefixes in the table when
theres no need
Hmmm.... Some interesting points:
- -- 2^32 is still larger than 2^20, which is claimed to be the largest
feasible size, above.
- -- BGP is currently moving to a 2^32 space for AS numbers. That's odd,
if there's only 18,044 origins in the current table, and it won't ever
grow to much more--how'd we lose 40,000 or so AS numbers, that we now
need more than 64,000?
Just curious.
Russ
- --
riw@cisco.com CCIE <>< Grace Alone
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joe Abley wrote:
- -- BGP is currently moving to a 2^32 space for AS numbers. That's odd,
if there's only 18,044 origins in the current table, and it won't ever
grow to much more--how'd we lose 40,000 or so AS numbers, that we now
need more than 64,000?http://www.nanog.org/mtg-0510/huston.as.html
http://www.nanog.org/mtg-0510/wilhelm.html
From the second source:
"If all these unused ASNs could be recovered, the pool of ASNs would
last until 2025 to 2030."
So, if we think that 2^32 is ultimately unobtainable, we're just facing
a deadline with 2^32's being the "norm" per AS of a few years longer. Of
course, this doesn't even answer the question of how to get from 2^18
currently, to 2^32 in the first place.
Russ
- --
riw@cisco.com CCIE <>< Grace Alone
I think someone at CAIDA or even Renesys could put out some good numbers
for 'origin' AS counts and even 'AS in aspath' It's slightly higher than
18k, but not 40k higher 
At last look (during arin/nanog meeting) it was
about 20k unique origins (from 701 perspective as seen through
routeviews)
Per the latter -
"... We show that this is due to two effects: (1) ASNs which are
assigned based on future plans but never used in practice, and (2) ASNs
which are no longer in use but not returned to the RIRs. If all these
unused ASNs could be recovered, the pool of ASNs would last until 2025
to 2030. ..."
What about those that are assigned and used but not [currently] visible
on the public Internet [i.e., are on other internets]?
route-views routing tables is around 21,000.
Plenty of space to recover, even though some of those might be in private use (and might or might not be able to use private ASNs).
There just doesn't seem to be the political will to do so (e.g., by starting charging some amount of money per year, so dead/unpaid ones would be turned up). Or folks may consider that too big an effort compared to just upgrading to 4B as numbers now.
Seems a bit irresponsible to me. Personally I'd rather focus on cleaning up the AS number mess a bit rather than throwing more technology at the problem.
All the same, we need to start the technology throw now, because it's well
known that the cleanup won't happen until far too late - by the time it gets
painful enough that actual cleaning happens, we won't have enough lead time
to deploy technology.
Personally, I'd rather focus on making sure that a 75% complete cleanup doesn't
result in us falling 5% short with no alternate plan already in place and ready
to turn on.
From [bgp.potaroo.net], the number of all ASs seen in all the
route-views routing tables is around 21,000.Plenty of space to recover, even though some of those might be in
private use (and might or might not be able to use private ASNs).There just doesn’t seem to be the political will to do so (e.g., by
starting charging some amount of money per year, so dead/unpaid ones
would be turned up). Or folks may consider that too big an effort
compared to just upgrading to 4B as numbers now.Seems a bit irresponsible to me. Personally I’d rather focus on
cleaning up the AS number mess a bit rather than throwing more
technology at the problem.
Its true that we see only some 20,700 AS’s in the BGP table today, and its also true that there are some 12,500 unadvertised AS’s that have been assigned by the RIR system (and its predecessors), and some 6,600 AS numbers held in the RIRs that they are currently allocating from ( http://www.potaroo.net/tools/asns)
The AS story is about the trends in recent times, which see a best fit of an exponential growth model to the past 3 years of AS number allocations by the RIRs, and if we assume no change in AS number policies, and no change in the trend of ageing out ‘old’ AS numbers at a rate of some 5% per year into the unadvertised pool, then the 2byte field will exhaust sometime in October 2010.
At that time there will be some 40,000 advertised AS numbers and some 20,000 unadvertised AS numbers.
The discussion of whether there are ‘natural’ limits to AS number consumption is an interesting one - it seems that more smaller sites are multi-homing now, and the pressure for more AS numbers in the routing system appears to be based strongly in the area of distinct routing policies in an ever-richer inter-AS connectivity mesh ( http://www.potaroo.net/ispcol/2005-08/as.html contains one view of this). I’m of the view that this consumption trend reflects a behavioural trend in routing that is going to prove difficult to stop, and what we will see is a steady growth in the number of stub AS numbers that perform no transit at all. Is AS reclaimation an option? We don’t know how many ‘dark’ (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. We don’t know whether this use of AS numbers will continue to grow. The recent data suggests a steady growth in the unadvertised AS count, but not at the same rate as advertised AS numbers. How much time would aggressive reclaimation buy us? Current figures indicate that it would work for 3 years if we were able to reclaim ALL unadvertised AS numbers and recycle them. How much effort would it take to get this additional 3 years? Is it worth it when ytou consider that the only AS domains trhat actually need to run the NEW BGP code are thos routing domains that use AS numbers with a non-zero high-order two bytes. So, as I see it, the requirement for 4-Byte AS numbers is, at the present, very much a ‘when’ not ‘if’ question.
regards,
Geoff
RIRs, and if we assume no change in AS number policies, and no
change in the trend of ageing out 'old' AS numbers at a rate of
some 5% per year into the unadvertised pool, then the 2byte field
will exhaust sometime in October 2010.
no waffling. you said october 14th, and we're holding you to it!
we would like to know about what time of day, so we can schedule
lunch and coffee.
Is AS reclaimation an option? We don't know how many 'dark'
(unadvertised) AS numbers are used as VPN IDs in 2547 contexts.
do we care? i.e. does it affect the real public internet. are
these not like 1918?
Current figures indicate that it would work for 3 years if we
were able to reclaim ALL unadvertised AS numbers and recycle
them. How much effort would it take to get this additional 3
years?
and how much money will lawers make off the ensuing riot?
randy