[this is going to be a long and sort of whiny one, apologies in advance] [EMAIL PROTECTED] wrote: [..] >> As such, you as an ISP will get more than enough address space. > > Please now go and read draft-dickson-v6man-new-autoconf-00.
I was not interested at all in reading it as your presentation already contains a lot of misconceptions, which you then presented at NANOG, to a group of people who will then get even more misconceptions as they don't have the time to read through a bulk of text either. They will though maybe have seen the presentation and think that is the current state of play, which it is not. > It goes into why having ISPs get more space from RIRs is a bad thing. Thus your presentation doesn't reflect what you are actually are trying to target, while it caries the title of the same draft? Sorry, but not everybody wants to read through a bulk of text, especially with a non-technical introduction of nearly three pages, but most people will assume that the presentation, though in less detail, at least covers the same content as the draft on the same subject and of the same name and hopefully then is also concise and correct. > 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.) There are already a couple ISP's who got prefixes between /20 and /32 who are currently de-aggregating it. Changing where the user-bits are, is not going to change that. That is is in the hands of the ISPs who either accept or don't accept those prefixes. One can easily take the the IPv6 stats files provided by the RIRs and make prefix filters based on that, thus only accepting exactly the allocations that have been actually allocated by the various RIRs. If that is what you want of course. But, that won't work either, as I have previously mentioned already, there are several ISP's who went to the various RIRs and gotten chunks from all of them. Some even simply asked for separate (though aggregatable) chunks from the RIR, a /32 per country. You are mixing up Addressing with Routing. You are trying to solve a Routing issue by changing Addressing. Please see the [EMAIL PROTECTED] and [EMAIL PROTECTED] who are attempting to solve that issue. Also note that the whole idea of giving a /48 (or currently being proposed a /56*) to end-sites has a real reason: so that those users get (64-48=) 16 bits to play with. (* = the /56 for home-sites is a good idea IMHO and would indeed give a bit more space to ISP's. It is a MUCH better idea than changing EUI-64 though, which can sort of be seen as wasteful, but it is not) Of course, such an end-site can always decide to either get more /48's if they are really that big. Or they can do DHCPv6 and deal out /126's. That really is the end-sites problem. The EUI-64 is there as it will cater for all, not only a few. > More importantly, the slides were to generate interest in reading the > larger document. But as the slides already contain a lot of misconceptions, my interest is not raised at all to even look at it as it will only contain more of that. > Obviously, I would have preferred giving a long lecture > on the whole ball of wax (not!). ...oooOO( If you have no interest in actually correctly presenting and thus defending your draft, then why do it? ) > 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. As there was no discussion about the subject yet on any of the lists that I know about, lets discuss it now that we at least have your attention and that of a few others. [..] >> ====== >> 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. They can already. They get 128-(16~32)-48 of address bits. They can provide their network layout to the RIR they are requesting their prefix from and voila. If you need more bits between that, justify them and get them, it really is that simple. [..] > 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. Ever heard of the concept of "HD ratio"? Hint: there is an RFC and it is what RIRs and ISPs use to calculate how large their IPv6 allocation is supposed to be. [..] >> 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? Which exact impacts of /64's? Or are you wanting to stuff /64's into global BGP? ISPs are getting /16-/32's and for PI /40-/48 are being allocated by the RIRs. How is this going to affect global prefixcount? Especially if ISPs decide to simply filter per the stats file and only accept what was allocated. De-aggregation will happen if other ISPs allow it. If they don't then it won't happen. Also a router doesn't see a difference between routing a /128 or a /64. Both are one entry. In the best case the /64 can even be stuck into a smaller entry if wanted (eg buckets for /64's) and thus contain less space. Then again I am not building routers for a living so I can be totally wrong there, but I really don't see a difference. > How easy is it to change the RFCs, when the deployed mess is 30,000 > prefixes? 100,000? 250,000? If you want to save 'bits', then start assigning /56's to your customers, then you get 8 bits "back". Doing /56's makes much more sense and doesn't require any changes at all in any of the architectures that have been established 10 years ago. > We don't currently have too much info on the end-site uptake, IMHO. Start promoting IPv6 and start deploying it then. Steering offtopic for this a bit, I heard a rumor that went along the lines of "Yeah, in the ARIN region most new prefixes directly get turned up and thus our deployment is faster" Not so odd, as before the PI space was possible there where nearly no allocations in ARIN land, but still, how does that translate to actual deployment (at least looking from BGP if they are active). Lets check GRH (http://www.sixxs.net/tools/grh/ for folks who don't know it yet ;) RIPE : 760 / 391 / 51.45% ARIN : 470 / 154 / 32.77% <--- 20% less in comparison to RIPE/APNIC APNIC: 346 / 186 / 53.76% So what was so good about that again. Please US folks, stop doing PR about that you are going to and start deploying! Do note that ARIN now has more prefixes than APNIC. Still both APNIC and ARIN have only 50% of the prefixes online that RIPE already has. That is quite some way to go folks! See the various other stats on the GRH site and potaroo etc for other perspective on allocation etc. [..] > Look forward to ongoing discussions on this topic.... > > But, please, tell me if/when you have read the draft-dickson... itself? I, for a moment, ignored the content of your presentation, which according to you doesn't represent actually what you want to state in the draft but is more a sort of tabloid thing to call for attention. I have now fully read your draft, word for word, just to be able state that I did. Still I can't find anything in there which would even remotely justify even thinking of changing the EUI-64 concept, mostly as the same misconceptions in the presentation are being made in the draft. It read like a great advertisement, though high on bla-bla, and it will probably work great if you need to raise venture capital or want to write a 20 page paper for a conference, unfortunately it has nothing to do with technical requirements or argumentation. Nice use of buzzwords though and repeating of things that are available in other places, though then with a twist which indeed are basically misconceptions. eg 2.1 "Existence", a /48 is *HUGE*, probably too large for most end-sites, these will also never have to renumber (unless swapping ISPs) Looking at the PI space that ARIN is allocating, and most of it being /48's, this clearly is the case that nobody think they will be bigger. The ones that need more space are getting a larger block directly or can later on get an additional /48. Aggregation there is not a big issue, and you really will not be jumping from one /48 to a 1000 or so of them. If you are, then one really did some mismanagement and misplanning ;) Please show me a network design at a single site which will use more than a /48 and completely fill it up. (which would produce 65k routes in your internal routing tables if you would not properly aggregate, which you can easily do, but that is left as an exercise to the reader). The whole point: if you need more address space go to your RIR and justify it and get it. Note also that the whole idea of IPv6 allocations is that an ISP will *never* come back again. Take a guess why some ISPs got a /20 and there are rumors of this $organization getting a /13... You might have to pay a few more $localcurrency, but if your network is that big, do those really matter then? Btw: "3.1. Current Allocation Techniques" states "End User Assignment Size: Typically /56" which really is bogus at the moment. It might be a good way to change to it. But really the blocks are sized /48 at the moment. This is also the size that ISP's justify their /32 or larger on. If they would change this themselves to a /56 some would not be able to justify a /32 anymore... in that same part: " Note that these large initial allocations actually *support* the proposition that more bits are needed - otherwise, why would such large allocations be being made?" Because those are multi-million customer ISP's and they have justified that they need multiple-millions of /48's for their customers. The problem for your complete draft is answered, by yourself, already with that part. "Reservation for Growth to the ISP: Typically 4 bits" do you note that 4 bits is a power of 4 times the huge amount of space that they already have? Do you think that is not enough? Especially considering that they have justified their allocation request with room to spare for the future. As such if they run out of the first /32, and the second, and the third, they clearly did something wrong there. The rest of the draft covers how to change it and the appendixes. For the stuff in the appendixes see the HD ratio RFC which covers similar tables, but then with real math behind it and argumentation. I would suggest taking a real live ISP network and making a network diagram for that and how you would chunk up that /32 or larger that you get from the RIR. Then see if you still have possible 'growth' issues. Clearly if you need more address space, again, you go to your RIR and ask for more, hopefully in one big chunk. If you did your work correctly while planning you already made that design though and would have passed it on to your RIR who then would automatically (unless it was ridiculous) have given you that prefix-size you need simply on the basis that you have justified it. Now that I read the draft, and pointed out a few of my concerns, did I totally miss the picture or what? As I really still don't see the need for changing any of the current way things work. The real solution to your 'problem' is the change of /48 -> /56 for endsites. But you can easily take this up with the RIRs, it has nothing to do with the architecture of things. 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 --------------------------------------------------------------------
