> Hi, > > I just noticed > http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf > and found some serious flaws and most likely misunderstandings in the > way that some things are presented in there. It was already publicly > presented at the NANOG meeting, so lets discuss ;) > > <insert humble mode disclaimer etc /> > > ======= > Slide 9: Of course you can ignore it, just use DHCP. Only fe80::/10 is > fixed to use EUI-64 at the moment. Everything else, if you want can be > done with /126's if you really want. But that defies the whole idea of > stateless autoconfiguration. Nevertheless, if you really want, you can. > > But why would you? As an ISP you go to your RIR and the RIR allocates > you a block of address space (generally a /32 or much larger) based on > how many customers you expect to have times /48 + some HD-based overhead. > > As such, you as an ISP will get more than enough address space.
Please now go and read draft-dickson-v6man-new-autoconf-00. It goes into why having ISPs get more space from RIRs is a bad thing. Even if space is available, there is no guarantee that ISPs getting multiple /32's will announce them only as aggregates. (IPv4 deaggregates are the demonstrable support for that particular argument.) More importantly, the slides were to generate interest in reading the larger document. Obviously, I would have preferred giving a long lecture on the whole ball of wax (not!). But, in the absence of presenting that, I had to hit enough of the highlights to get folks over here, and get folks to read the draft itself. > ======== > Slide 10/11: You don't reserve any bits for customers. They are already > getting a /48 which should be *way more than sufficient* for their > purposes. If they really will need more than 65536 /64 based networks > they will already have such a large network now, and thus can tell you > "hey we need a /47" or something, or they will at a certain point run > out and come back and you give them another /48, which does not really > have to be consecutive. Most of those very large networks though will > simply request PI space. As such they are not your worries. > > If you are reserving space you clearly misunderstood the whole idea of > the /48's. > > Also, there have been plans already (eg by Thomas Nartens) to make the > default assignment size /56 to end-users. Companies would still get > /48's though. > > > Why would this "squeeze the ISP?", you can get as much space from your > RIR as you require. Same as for IPv4. Justify and receive. > > ====== > Slide 12: IMHO you indeed really don't get it ;) > > Does it matter if you have /40's routed to your distinct PoPs, thus > geo-aggregated, and then route /48's from each PoP to the customer, or > make this a difference when you make that into /48's and /64's > respectively? The route count will remain the same. What matters (and this is the main reason for the whole set of proposals), is the *ability* of the ISP to aggregate however they want. It does not matter one whit, what the absolute size of the things are, aggregates and more-specifics. My draft includes some tables, showing how many different (non-vlsm, but hierarchical subnet) schemes can be carved out from a set of bits, where a particular lower bound on the size of each level of the hierarchy in bits is specified. I have a script for taking bits (range) and bits (min size), to calculate the permutations of hierarchies that can be produced. In the appendix, I list some of them, and summarize the counts for others. If you'd like, I can post the script source (perl), and play with it, to see how limiting it is, to not have enough bits, when you have a network topology that predicates a certain number of aggregation points based on that topology (dslams, routers, pops, regions, whatever). > Note also that there are still not 1000 IPv6 prefixes globally... And, should experience at some later point show that my proposition on the impact of /64 holds true, what then? How easy is it to change the RFCs, when the deployed mess is 30,000 prefixes? 100,000? 250,000? We don't currently have too much info on the end-site uptake, IMHO. And that is the kind of thing that would help the drill-down on some of the assumptions on all sides.... > Greets, > Jeroen Look forward to ongoing discussions on this topic.... But, please, tell me if/when you have read the draft-dickson... itself? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
