On Fri, 1 Feb 2002, Tony Hain wrote: > To serve a million the service provider will need at least a /28, and > probably a /27 where is the problem? If you are assuming that the rir's > won't allocate a /27 to a provider that can document allocation to a > million customers then we have a problem with rir policy not being > applied consistently with what is documented.
That's fine - my question was, because of the regionalisation and scoping for growth in network deployment, whether a /27 was enough (if you did use RFC3194 and its 0.8 HD ration you'd need a /23 for 1 million objects, but given the provider is in sole control of one network, I agree it should be far more efficient). > There are active discussions about changing the slow-start. We will have > to see what happens, but I believe a /32 is likely. I really doubt that > a provider would have a hard time getting a /27 if they walked in with a > list of a million customers and said here is our plan for allocating > /48's statically to each of them. As I understand it, the rir policy is > intended to ensure efficient allocation, not dictate a business practice > of dynamic allocations. If you have evidence to the contrary please > speak up. No, just an observation that the static/dynamic issue is not discussed in the IESG recommendations document. Perhaps it shouldn't be, but if providers read it, some reference may be useful (static /64 is mentioned for mobile networks, but of the five example recommendations, only that one explicitly says static). I would hope registries would not refuse an allocation based on the fact that they wished to make static allocations, if say only 75% of their customers were connected at one time and they could thus save a few bits of space by dynamic allocations. (The question then is why would a provider use dynamic allocations - presumably as a means to resize/juggle their network, though at present it's often used, even with free ddns services available, to deter people from running services from their home networks, which is exactly what we want IPv6 for...). > > I observe, as a BT ADSL customer, 9 hops from my NAT box to > > the BT Internet > > gateway. > > Sounds like a personal problem of provider selection... ;) > My dsl is 3 hops from the nearest border router. I didn't say BT Openworld was the best :-) I recall it was more hops until recently, and that for one trace I hit the default 30 hop limit...(!) But it's an indication that address utlisation won't be as good as people may hope? > ...... One of the big problems I see > from a long-term perspective with static assignments is 'how portable > are the addresses?' If customers can move around the topology and keep > the same address, the complexity goes way up and the HD ratio goes way > down (actually if you treated the entire /28-48 as a single flat-route, > the HD ration could hit 100%). If on the other hand the addresses were > static with topology, it would be fairly straight-forward to align the > sub-allocations along with population/pop-density (a town with ~1000 > residents won't need more than a /38). I was assuming the static addresses were aligned with topology. Then the premise would be that your IPv6 prefix is static for the home you are in, if you keep the same provider. Having considered an addressing plan for a national academic network, I don't know how (say) a plan for a BT Openworld IPv6 deployment might look (apart from more complicated than your provider's, I expect!). The static prefix I agree has implications for the provider in planning the deployment, and their ability to reshuffle their addressing scheme as the topology and regional demand changes. Perhaps the IESG proposal should have a section on this, if it's deemed appropriate and revelant? Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
