Addenda
LOBs and the LOBINDEX: If a LOB is defined as 'enable storage in row' the first few chunk pointers (up to 12 it seems) are stored in the row, so for collections of small LOBS, the lobindex may never be used at all. If the LOB is defined as 'disable storage in row' then no space is used in the base table for chunk pointers.
Errata
The largest legal value for CHUNK is 32K - my sample text (p. 367 and following) uses 64K. I also hypothesise a 6MB chunk size in a 10MB extent (p.368), but this is a non-event. The largest chunk size appears to be dictated by the largest possible Oracle block size. It seems a little surprising that you can't set a chunk size up to at least 1MB, given that some operating systems are able to handle single I/O requests of 1MB, however with the read-ahead algorithms that Oracle is now using, you may find that a 32K chunk read often results in a read-ahead that gives you most of the benefit of a large chunk-size anyway.
I state that all current entries in the lobindex contain 4 chunk pointers (p.368). On subsequent tests this seems to be 8 chunk pointers for all entries other than the first. It is possible that this is dependent on block size, or even dependent on platform. I will also be reviewing the accuracy of my claim (fig 17-3 p.373) for the number of chunks listed in a lobindex entry for out-of-date 'SCN-loaded' chunks.