Tim Chown wrote: > The question is, if a service provider wants to follow the > recommendation > for a /48 allocation for a connected site, and the provider wants to > offer static /48's to always-on sites, won't it hit trouble > whether it is > using a /35 or a /29? If you say "either there are enough > prefixes to > route the currently connected customers or there aren't" then > you're saying > either we will have ISP's out there who can allocate static > /48's to sites, > or we won't. It'd be nice if the answer was that we will... > even if that > provider has a million customers.
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. > > I feel we're in a slow start inside a slow start and that > will be harmful, > because providers won't offer the /48 because there's not > enough headroom. > OK, a static /64 is better than today's (typical) dyanmic single IPv4 > address, I agree :-) 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. > > 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. 1 * * * Request timed out. 2 18 ms 18 ms 18 ms a4-3-1.evrtwa1-aa2.bbnplanet.net [4.24.255.193] 3 20 ms 20 ms 18 ms p7-0.evrtwa1-cr2.bbnplanet.net [4.0.79.129] 4 18 ms 18 ms 24 ms p3-0.evrtwa1-br2.bbnplanet.net [4.24.5.109] > The question then is whether the provider can build an > architecture to 100% utilise the address space (unlikely), or > if not to > what extent the address space can be used, in a wide area > deployment (e.g. > for BT xDSL across the UK)? It should be better than > RFC3194, but how > much better? CAN or WILL ?? It is certainly possible and easy to build complex infrastructures that don't scale well, but usually hard to build simple ones that naturally align with growth. 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). > My own view is that a static prefix is very important. > Certainly a "decent > DDNS infrastructure" would have to deal with significantly > more renumbering, > and more rapid renumbering, application awareness, more > lookups with lower > TTLs, firewalling problems (I set up access to let my friend > copy files > from my MP3 server, but oops his prefix just changed), issues > where the > Mobile IPv6 home agent/prefix is really in the home, etc. > Thus the DDNS > infrastructure has to fit the model where the servers are on > the networks > with the dynamic addresses. It just seems so much easier to > assume static > home prefixes. But if we want that, the implications for > the providers' > allocations needs to be addressed. I agree and would be happy if all service providers were enlightened enough to *want* to provide static prefixes. If someone with a million existing customers has tried to show the rir's a plan for a static prefix assignment network and failed, I would like to know so a few of us can start working the issue. In any case I believe a robust ddns is required, and would prefer to see that as an edge service (ie: set-top) with the access device providing a nice, stable, single-point-needing-auth server for local devices that come and go on a frequent basis. It also makes the problem of ddns auth within the home easier because that can all be based on site-local addresses which the edge device knows didn't come through it from the public side. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
