Brian Dickson wrote: [..] > If an ISP gets a /32, and gives out /48's, which they can do without > requiring supporting documentation, > and reserves space for each allocation (say a nibble), that leaves only > 12 bits of "range", or 4096 customers.
You do realize that a /48 is *65536* /64's and as such there will be only very view sites worldwide which will ever need more? You also realize that these sites are already very large and can easily justify another /48, either adjacent or not from their upstream address provider, may that be a LIR or RIR. > I dare say that there are a fair whack of ISPs with that many customers, > who are most likely to get only > a /32. Please check http://www.sixxs.net/tools/grh/dfp/ it clearly shows that there are today at 2x /19, 6x /20 and various other large blocks. > Even *if* RIRs are reserving space for them adjacent to those original > assignments, there is nothing that > would stop anyone from announcing two adjacent /32's instead of a /31. [..] That is not a problem that the IETF or the RIR's can fix. IETF define protocols, the RIRs provide address space based on those specifications and how their members want them to be allocated. ISPs use it, and they use it in any way they want. See again above URL, but then /tools/grh/lg/ for a nice looking glass showing you that various ISPs are already de-aggregating but also that quite a number of ISPs are using the 'strict filter' set already as per http://www.space.net/~gert/RIPE/ipv6-filters.html and thus are cutting out all more specific announcements. Note also that GRH nicely colors those in the looking glass when looking for 'bogons', though it doesn't tag them as completely evil, just something which should not be there. If this de-aggregation is going to cause too much entries (there are only ~900 today!) then ISPs who will have problems with their routers will start applying prefix filtering, taking those sub-allocs out of the loop. The real solution to your perceived routing problem is being discussed on [EMAIL PROTECTED] The big problem though remains always that one will need to have the information in as-good-as realtime to know where you have to route your packet, as such you will most likely need a more or less full table to do that, or at least a table of 'I talked to them before' kind of prefixes. Changing the distribution of address space won't solve this problem at all though. As instead of a /48 being inserted in BGP from one ASN, they will just insert a /64. The real thing that can avoid that is ISPs filtering and the ones wanting to insert them not being able to pay enough to convince ISPs that they should accept theirs. Greets, Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
