On Fri, 1 Feb 2002, Tony Hain wrote: > Did the term 'slow-start' get lost somewhere? As I understand rir > policy, the /35 was never intended to be the only allocation a serious > ISP would get. Static vs dynamic is a non-issue, because either there > are enough prefixes to route the currently connected customers or there > aren't. If a service provider wants to allocate prefixes to customers > that aren't connected, they will need a larger block than the one that > allocates dynamically based on connected status.
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. 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 :-) > Within the context of a pop, why not? The only reason this would not be > the case is when a provider considers the allocation to be disjoint from > current connected status (ie: static assignment) and the measurement is > done on the connected set rather than the allocated set. The HD ratio > should be calculated on the allocated set no matter if that is static > or dynamic. I observe, as a BT ADSL customer, 9 hops from my NAT box to the BT Internet gateway. 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? > I can already hear the 'what about renumbering nodes?' question. There > is no reason for this to be an issue. Address use is defined to match > the smallest scope appropriate for the connection, so intra-site/on-link > communications will be immune to changes in the global prefix. If a site > is currently disconnected from the service provider, there is no reason > for it to have a global prefix floating around. The only reasons for an > ISP to make static prefix assignments would be if the site wanted stable > DNS entries, but with a decent DDNS infrastructure that is not even > required. 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. 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] --------------------------------------------------------------------
