- NANOG - lists.nanog.org

Re: Cablevision/OptimumOnline Long Island - massive outage
by Sean Donelan 04 Sep '00

04 Sep '00

On Sun, 03 September 2000, Kai Schlichting wrote: > What could bring down such a large cable system in parts and repeatedly > for many hours at a time is beyond me: one of my SSH sessions just In my experience, its usually a combination of operator error and hardware problems. I've accidently killed a network for 8+ hours. Its amazing how a system can appear to be very stable, and then become irrecoverable after an apparently insignificant change.

1 0

Cablevision/OptimumOnline Long Island - massive outage
by Kai Schlichting 03 Sep '00

03 Sep '00

Cablevision/OptimumOnline, Long Island, NY has massive roving outages of their cable Internet service swince Friday evening: calling their customer service line gets you 30+ min. waits before a drone answers who will ask if you power-cycled your cable modem and computer, then puts you on hold for another 30+ (I was too impatient to wait longer) to wait for a "technician". The list of cities effected by the outage seems to change (on their on-hold tape) every 2 hours, is somewhere between 6-10 cities at a time, and in 4 calls, I have heard probably 30 different city names by now :) What could bring down such a large cable system in parts and repeatedly for many hours at a time is beyond me: one of my SSH sessions just resumed from being stuck for 11+ hours: Modifying your TCP kernel (or registry - your platform pick) settings to not time out for a few days is a really good idea :) bye,Kai

2 1

Re: bring sense to the ietf - volunteer for nomcom
by smd＠clock.org 03 Sep '00

03 Sep '00

Oh yes, it was suggested that I point out that today is the deadline for volunteering. Also, that it would be nice to have more than two actual operators on the volunteer list (which is 84 persons long now)... Sean. echo 'I volunteer' | Mail -s 'NOMCOM VOLUNTEER' aboba(a)internaut.com

1 0

bring sense to the ietf - volunteer for nomcom
by smd＠clock.org 03 Sep '00

03 Sep '00

Dear Operators - Please take a moment to volunteer yourself for the next NOMCOM. There are an interesting set of IAB and IESG folks whose terms expire, and now is an opportunity to correct the historical under-representation of operators in the choice of appointees to I* bodies. It is pretty simple - check RFC 2727 and the message I attach below. Tell your friends & colleagues too. Sean. - -- Message-Id: <200008291928.PAA29406(a)ietf.org> From: "Bernard Aboba" <aboba(a)internaut.com> To: IETF-Announce: ; Subject: 3rd (and last) Call for nominations committee volunteers Date: Tue, 29 Aug 2000 15:28:10 -0400 Sender: scoya(a)cnri.reston.va.us Lines: 103 Hi - I've been selected to chair the 2000 IETF Nominations Committee, the committee that will select this year's nominees for the IAB and the IESG. The good news is that I don't have a vote. The bad news is that we need to find 10 volunteers to fill this year's NomCom. Details about the NomCom process can be found in RFC 2727. If you've already volunteered, you can check that you're on the volunteer list by looking at: http://www.drizzle.com/~aboba/internaut/nomcom2k.txt The NomCom is the IETF's way of choosing its leadership. Typically, half of the IAB and half of the IESG is selected each year. It is possible that the NomCom will have to fill more or fewer slots than this, due to the creation or elimination of positions by the IESG, resignations, transfers, etc. IESG members whose terms are up include Fred Baker, IETF Chair; Scott Bradner, Transport; Randy Bush, Operations & Management; Patrik Faltstrom, Applications; Thomas Narten, Internet; Dave Oran, Routing; and Jeff Schiller, Security. IAB members whose terms are up include: Harald Alvestrand, Ran Atkinson, Rob Austein, Steve Deering, Tony Hain and Geoff Huston. For the NomCom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Volunteering for the NomCom is also a good way of serving the IETF community. So please volunteer. NomCom members are barred from nomination during the year they serve, even if they later resign. Therefore being selected for the NomCom provides complete immunity against selection for the IAB or IESG during that year. People who volunteer should be sure they can the afford the time, several hours per week for the next 4-5 months. The task basically involves the following activities: - Reading candidate's statements - Participating in a weekly 2 hour conference call. - Attending the IETF meetings held during the selection process. - Doing several interviews. - Speaking to IETF participants about the candidates, the job requirements or the process. All NomCom deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The NomCom members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members are expected to handle this information in a manner consistent with its sensitivity. To qualify as a volunteer, a person needs to have attended 2 out of the last 3 IETF meetings. Anyone who meets this requirement is invited to volunteer by emailing your name, telephone number(s), and email address to aboba(a)internaut.com no later than September 3, 2000. Please put "NOMCOM VOLUNTEER" in the subject line. Once the list closes, I'll provide the list to the IETF secretariat for them to verify the eligibility of the each of the volunteers (e.g. has attended at least 2 of the last 3 IETFs). I will also ask them to publish the list prior to verification for volunteers to confirm that I actually got their email volunteering. We will then run the selection process and announce the results the week of September 11, 2000. Ten (10) NomCom voting members will be chosen from the pool of volunteers according to the procedure described by Donald Eastlake in RFC 2777, "Publicly Verifiable Nomcom Random Selection". The source of randomness will be based on the shares traded number of 12 stocks selected by the NomCom chair. The official shares traded numbers (denoted in 000s) will be drawn from the September 8, 2000 Wall Street Journal which reports the sales figures from the previous day - September 7, 2000. If trading in any of the stocks is suspended, then the shares traded will be assumed to be 0. Please volunteer. Please convince your friends to volunteer. Thank you, Bernard Aboba <aboba(a)internaut.com> STOCKS USED IN THE NOMCOM SELECTION PROCESS: eBay, Inc. (EBAY) Merill Lynch & Company (DJM) Digex, Inc. (DIGX) Dreyer's Grand Ice Cream (DRYR) Pepsico, Inc. (PEP) Target Corp. (TGT) Applied Materials, Inc. (AMAT) Norsk Hydro AS (NHY) Colgate Palmolive Company (CL) Maxtor Corp (MXTR) Home Depot, Inc. (HD) Boise Cascade Corp (BCC)

1 0

nanog down ?
by Jan-Ahrent Czmok 03 Sep '00

03 Sep '00

is nanog mailinglist down? Jan -- Jan Ahrent Czmok Head of International Peering Department Gigabell AG http://www.gigabell.net phone: +49 69 17084-716

2 1

RE: When IPv6 ... if ever?
by Roeland M.J. Meyer 03 Sep '00

03 Sep '00

> It doesn't make any business sense. The model is broken, > and as long as it's broken, large-scale deployment of IPv6 will > be extremely slow if it happens at all. This is kind of what I was getting to. IPv6 seems stuck in the same type of morass as new TLDs. Maybe, with less business potential.

2 1

Re: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting)
by smd＠clock.org 03 Sep '00

03 Sep '00

| Internet2 provides the same thing, only faster; I'm sorry, but parts of my network are ALREADY faster than Internet2's network by a factor of four. Other fully commercial networks are also well beyond the technology that most academics brag about. The ONLY interesting large-scale academic networking project is currently being done by CANARIE, which ironically I used to call a pretty bird with a beautiful song and no ability to fly anywhere. If you want to appreciate interesting research networking ignore both I2 and v6, check out the MANET stuff in the IETF, and try to get the folks there to think much bigger scale. Sean.

2 1

RE: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting)
by Morgan Dollard 03 Sep '00

03 Sep '00

I disagree, IPv6 is already significantly being deployed in the Inernet2. So far though that is only used by University and research orgs, kinda like Arpanet was in teh begining. Significant new applications are being deployed for it specifically, and great innovations are taking place. Eventually, that will replace the Internet as we know it today, and IPv6 will be implemented, unless someone comes up with anything better, which isnt that unlikely. Morgan -----Original Message----- From: smd(a)clock.org [mailto:smd@clock.org] Sent: Friday, September 01, 2000 15:56 To: David.Conrad(a)nominum.com; mohta(a)necom830.hpcl.titech.ac.jp Cc: nanog(a)merit.edu; ted(a)mirror-image.net Subject: Re: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting) | When, do you think, will IPv6 come someywhere close to being | significantly deployed? When pigs fly and the devil invests in snow-removal equipment. Sean. Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

7 8

FW: (ngtrans) IAB/IESG Recommendations on IPv6 Address Delegation
by Gregory Soo 02 Sep '00

02 Sep '00

-----Original Message----- From: Steve Deering [SMTP:deering@cisco.com] Sent: Friday, September 01, 2000 7:02 PM To: ipng(a)sunroof.eng.sun.com Cc: ngtrans(a)sunroof.eng.sun.com; Bob Hinden Subject: (ngtrans) Fwd: IAB/IESG Recommendations on IPv6 Address Delegation Appended below is the message that was sent today to the RIRs from the IAB and IESG, regarding IPv6 address allocation policy. It contains most of the material that was in the draft I forwarded here on Sunday, but reorganized into a more coherent document. Steve >-----Original Message----- >Date: Fri, 01 Sep 2000 12:40:48 -0700 >To: lir-wg(a)ripe.net (RIPE), policy(a)arin.net (ARIN), > apnic-talk(a)apnic.net (APNIC) >From: Fred Baker <chair(a)ietf.org> >Subject:IAB/IESG Recommendations on IPv6 Address Delegation >Cc: ipv6-directorate(a)sunroof.eng.sun.com, iesg(a)ietf.org, iab(a)ISI.EDU, > ipv6-wg(a)ripe.net (RIPE), sig-ipv6(a)lists.apnic.net (APNIC) > >Folks: > >The RIR community asked the IETF community for advice regarding the >assignment of IPv6 prefixes to service providers and edge networks, both >with a view to topological address assignment and to multihomed networks. >The IPv6 Directorate prepared a statement, which the IESG and IAB have >reviewed and approved. This is attached. > >I trust that this answers the questions you asked, and serves as a basis for >IPv6 deployment in the near term. If you have questions or issues concerning >it, I would suggest that you address them to the IPv6 Directorate copying >the IESG and IAB. > >We intend to publish an Informational RFC in the near future documenting the >contents of this note. > >Fred Baker > >----------------------------------------------------------------------- > > IAB/IESG Recommendations on IPv6 Address Allocations > September 1, 2000 > >Introduction > >During a discussion between IETF and RIR experts at the Adelaide IETF, >a suggestion was made that it might be appropriate to allocate /56 >prefixes instead of /48 for homes and small businesses. However, >subsequent analysis has revealed significant advantages in using /48 >uniformly. This note is an update following further discussions at >the Pittsburgh IETF. > >This document was developed by the IPv6 Directorate, IAB and IESG, and >is a recommendation from the IAB and IESG to the RIRs. > >Background > >The technical principles that apply to address allocation seek to >balance healthy conservation practices and wisdom with a certain ease >of access. On the one hand, when managing the use of a potentially >limited resource, one must conserve wisely to prevent exhaustion >within an expected lifetime. On the other hand, the IPv6 address >space is in no sense as precious a resource as the IPv4 address space, >and unwarranted conservatism acts as a disincentive in a marketplace >already dampened by other factors. So from a market development >perspective, we would like to see it be very easy for a user or an ISP >to obtain as many IPv6 addresses as they really need without a >prospect of immediate renumbering or of scaling inefficiencies. > >The IETF makes no comment on business issues or relationships. >However, in general, we observe that technical delegation policy can >have strong business impacts. A strong requirement of the address >delegation plan is that it not be predicated on or unduly bias >business relationships or models. > >The IPv6 address, as currently defined, consists of 64 bits of >"network number" and 64 bits of "host number". The technical reasons >for this are several. The requirements for IPv6 agreed to in 1993 >included a plan to be able to address approximately 2^40 networks and >2^50 hosts; the 64/64 split effectively accomplishes this. Procedures >used in host address assignment, such as the router advertisement of a >network's prefix to hosts [RFC 2462], which in turn place a locally >unique number in the host portion, depend on this split. Examples of >obvious choices of host number (IEEE Mac Address, E.164 number, E.214 >IMSI, etc) suggest that no assumption should be made that bits may be >stolen from that range for subnet numbering; current generation MAC >layers and E.164 numbers specify up to 64 bit objects. Therefore, >subnet numbers must be assumed to come from the network part. This is >not to preclude routing protocols such as IS-IS level 1 (intra-area) >routing, which routes individual host addresses, but says that it may >not be depended upon in the world outside that zone. > >The IETF has also gone to a great deal of effort to minimize the >impacts of network renumbering. None-the-less, renumbering of IPv6 >networks is neither invisible nor completely painless. Therefore, >renumbering should be considered an acceptable event, but to be >avoided if reasonably avoidable. > >The IETF's IPNG working group has recommended that the address block >given to a single edge network which may be recursively subnetted be a > >48 bit prefix. This gives each such network 2^16 subnet numbers to >use in routing, and a very large number of unique host numbers within >each network. This is deemed to be large enough for most enterprises, >and to leave plenty of room for delegation of address blocks to >aggregating entities. > >It is not obvious, however, that all edge networks are likely to be >recursively subnetted; an individual PC in a home, or a single cell in >a mobile telephone network, for example, may or may not be further >subnetted (depending whether they are acting as, e.g., gateways to >personal, home, or vehicular networks). When a network number is >delegated to a place that will not require subnetting, therefore, it >might be acceptable for an ISP to give a single 64 bit prefix - >perhaps shared among the dial-in connections to the same ISP router. >However this decision may be taken in the knowledge that there is >objectively no shortage of /48s, and the expectation that personal, >home and vehicle networks will become the norm. Indeed, it is widely >expected that all IPv6 subscribers, whether domestic (homes), mobile >(vehicles or individuals), or enterprises of any size, will eventually >possess multiple always-on hosts, at least one subnet with the >potential for additional subnetting, and therefore some internal >routing capability. Note that in the mobile environment, the device >connecting a mobile site to the network may in fact be a third >generation cellular telephone. In other words the subscriber >allocation unit is not always a host; it is always potentially a site. > >Address Delegation Recommendations > >The RIR communities, with the IAB, have determined that reasonable >address prefixes delegated to service providers for initial >allocations should be on the order of 29 to 35 bits in length, giving >individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber >networks. Allocations are to be given in a manner such that an >initial prefix may be subsumed by subsequent larger allocations >without forcing existing subscriber networks to renumber. We concur >that this meets the technical requirement for manageable and scalable >backbone routing while simultaneously allowing for managed growth of >individual delegations. > >The same type of rule could be used in the allocation of addresses in >edge networks; if there is doubt whether an edge network will in turn >be subnetted, the edge network might be encouraged to allocate the >first 64 bit prefix out of a block of 8..256, preserving room for >growth of that allocation without renumbering up to a point. However, >for the reasons described below, we recommend use of a fixed boundary >at /48 for all subscribers except the very largest (who could receive >multiple /48's), and those clearly transient or otherwise have no >interest in subnetting (who could receive a /64). Note that there >seems to be little benefit in not giving a /48 if future growth is >anticipated. In the following, we give the arguments for a uniform >use of /48 and then demonstrate that it is entirely compatible with >responsible stewardship of the total IPv6 address space. > >The arguments for the fixed boundary are: > > - only by having an ISP-independent boundary can we guarantee that a > change of ISP will not require a costly internal restructuring or > consolidation of subnets. > > - to enable straightforward site renumbering, i.e., when a site > renumbers from one prefix to another, the whole process, including > parallel running of the two prefixes, would be greatly complicated > if the prefixes had different lengths (depending of course on the > size and complexity of the site). > > - there are various possible approaches to multihoming for IPv6 > sites, including the techniques already used for IPv4 multihoming. > The main open issue is finding solutions that scale massively > without unduly damaging route aggregation and/or optimal route > selection. Much more work remains to be done in this area, but it > seems likely that several approaches will be deployed in practice, > each with their own advantages and disadvantages. Some (but not > all) will work better with a fixed prefix boundary. (Multihoming > is discussed in more detail below.) > > - to allow easy growth of the subscribers' networks-no need to > keep going back to ISPs for more space (except for that relatively > small number of subscribers for which a /48 is not enough). > > - remove the burden from the ISPs and registries of judging sites' > needs for address space, unless the site requests more space than a > /48, with several advantages: > > - ISPs no longer need to ask for details of their customers' > network architecture and growth plans > - ISPs and registries no longer have to judge rates of address > consumption by customer type > - registry operations will be made more efficient by reducing the > need for evaluations and judgements > - address space will no longer be a precious resource for > customers, removing the major incentive for subscribers to > install v6/v6 NATs, which would defeat the ability of IPv6 to > restore address transparency. > > - to allow the site to maintain a single reverse-DNS zone covering > all prefixes. > > - If and only if a site can use the same subnetting structure under > each of its prefixes, then it can use the same zone file for the > address-to-name mapping of all of them. And, using the > conventions of RFC 2874, it can roll the reverse mapping data > into the "forward" (name-keyed) zone. > >Specific advantages of the fixed boundary being at /48 include > > - to leave open the technical option of retro-fitting the GSE > (Global, Site and End-System Designator, a.k.a "8+8") proposal for > separating locators and identifiers, which assumes a fixed boundary > between global and site addressing at /48. Although the GSE > technique was deferred a couple of years ago, it still has strong > proponents. Also, the IRTF Namespace Research Group is actively > looking into topics closely related to GSE. It is still possible > that GSE or a derivative of GSE will be used with IPv6 in the > future. > > - since the site local prefix is fec0::/48, global site prefixes of > /48 will allow sites to easily maintain a simple 1 to 1 mapping > between the global topology and the site local topology in the SLA > field. > > - similarly, if the 6to4 proposal is standardized, migration from a > 6to4 prefix, which is /48 by construction, to a native IPv6 prefix > will be simplified if the native prefix is /48. > >Note that none of these reasons imply an expectation that homes, >vehicles, etc. will intrinsically require 16 bits of subnet space. > >Conservation of Address Space > >The question naturally arises whether giving a /48 to every subscriber >represents a profligate waste of address space. Objective analysis >shows that this is not the case. A /48 prefix under the Aggregatable >Global Unicast Address (TLA) format prefix actually contains 45 >variable bits, i.e., the number of available prefixes is 2**45 or about >35 trillion (35,184,372,088,832). If we take the limiting case of >assigning one prefix per human, then the utilization of the TLA space >appears to be limited to approximately 0.03% on reasonable >assumptions. > >More precisely, > > - RFC 1715 defines an "H ratio" based on experience in address space > assignment in various networks. Applied to a 45 bit address space, > and projecting a world population of 10.7 billion by 2050 (see > http://www.popin.org/pop1998/) the required assignment efficiency > is log_10(1.07*10^10) / 45 = 0.22. This is less than the > efficiencies of telephone numbers and DECnetIV or IPv4 addresses > shown in RFC 1715, i.e., gives no grounds for concern. > > - We are highly confident in the validity of this analysis, based on > experience with IPv4 and several other address spaces, and on > extremely ambitious scaling goals for the Internet amounting to an > 80 bit address space *per person*. Even so, being acutely aware of > the history of under-estimating demand, we have reserved more than > 85% of the address space (i.e., the bulk of the space not under the > Aggregatable Global Unicast Address (TLA) format prefix). > Therefore, if the analysis does one day turn out to be wrong, our > successors will still have the option of imposing much more > restrictive allocation policies on the remaining 85%. > > - For transient use by non-routing hosts (e.g., for stand-alone > dial-up users who prefer transient addresses for privacy reasons), > a prefix of /64 might be OK. But a subscriber who wants "static" > IPv6 address space, or who has or plans to have multiple subnets, > ought to be provided with a /48, for the reasons given above, even > if it is a transiently provided /48. > >To summarize, we argue that although careful stewardship of IPv6 >address space is essential, this is completely compatible with the >convenience and simplicity of a uniform prefix size for IPv6 sites of >any size. The numbers are such that there seems to be no objective >risk of running out of space, giving an unfair amount of space to >early customers, or of getting back into the over-constrained IPv4 >situation where address conservation and route aggregation damage each >other. > >Multihoming Issues > >In the realm of multi-homed networks, the techniques used in IPv4 can >all be applied, but they have known scaling problems. Specifically, >if the same prefix is advertised by multiple ISPs, the routing tables >will grow as a function of the number of multihomed sites. To go >beyond this for IPv6, we only have initial proposals on the table at >this time, and active work is under way in the IETF IPNG working >group. Until existing or new proposals become more fully developed, >existing techniques known to work in IPv4 will continue to be used in >IPv6. > >Key characteristics of an ideal multi-homing proposal include (at >minimum) that it provides routing connectivity to any multi-homed >network globally, conserves address space, produces high quality >routes at least as well as the single-homed host case previously >discussed via any of the network's providers, enables a multi-homed >network to connect to multiple ISPs, does not inherently bias routing >to use any proper subset of those networks, does not unduly damage >route aggregation, and scales to very large numbers of multi-homed >networks. > >One class of solution being considered amounts to permanent parallel >running of two (or more) prefixes per site. In the absence of a fixed >prefix boundary, such a site might be required to have multiple >different internal subnet numbering strategies, (one for each prefix >length) or, if it only wanted one, be forced to use the most >restrictive one as defined by the longest prefix it received from any >of its ISPs. In this approach, a multi-homed network would have an >address block from each of its upstream providers. Each host would >either have exactly one address picked from the set of upstream >providers, or one address per host from each of the upstream >providers. The first case is essentially a variant on RFC 2260, with >known scaling limits. > >In the second case (multiple addresses per host), if two multi-homed >networks communicate, having respectively m and n upstream providers, >then the one initiating the connection will select one address pair >from the n*m potential address pairs to connect from and to, and in so >doing will select the providers, and therefore the applicable route, >for the life of the connection. Given that each path will have a >different ambient bit rate, loss rate, and delay, if neither host is >in possession of any routing or metric information, the initiating >host has only a 1/(m*n) probability of selecting the optimal address >pair. Work on better-than-random address selection is in progress in >the IETF, but is incomplete. > >An existence proof exists in the existing IPv4 Internet that a network >whose address is distinct from and globally advertised to all upstream >providers permits the routing network to select a reasonably good path >within the applicable policy. Present-day routing policies are not >QoS policies but reachability policies, which means that they will not >necessarily select the optimal delay, bit rate, or loss rate, but the >route will be the best within the metrics that are indeed in use. One >may therefore conclude that this would work correctly for IPv6 >networks as well, apart from scaling issues. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Fred Baker | 519 Lado Drive >IETF Chair | Santa Barbara California 93111 >www.ietf.org | Desk: +1-408-526-4257 > | Mobile: +1-805-886-3873 > | FAX: +1-413-473-2403

1 0

Re: When IPv6 ... if ever?
by Richard A. Steenbergen 02 Sep '00

02 Sep '00

On Sat, 2 Sep 2000, Roeland M.J. Meyer wrote: > 3) Conservatively, every recent linux node has IPv6 kernel support and > every Windoze box can do IPv6 (not to mention what we have just heard > from the BSD camp <g>). This is over 50% of the leaves out there > (conservatively). At what point is there sufficient market penetration > of the technology to consider rolling IPv4/IPv6 > interoperability/capability on the core routers and switches (something > short of 100%, I would hope)? > > 4) Is it maybe that Sun, HP, Intel, Cisco, IBM, and the telco's, aren't > all quite ready yet? There are two key problems which are preventing the widespread use of IPv6, IP Allocation, and network vendor support. Support for all hosts is actually one of the least of the problems. Think of it this way, major networks want to deploy IPv6... How do they do it? They certainly can't do it on their primary backbone links and routers, the support from vendors is simply not there. Even if there was working code, they wouldn't dare deploy it on their production network, the code is too unstable (especially IPv6 routing protocols), and they risk looking unreliable in comparison to those who don't even make the attempt to support IPv6. So what do they do? Without the network there is not the demand for high traffic IPv6, and without the demand there is little desire to build the network. Should they buy seperate routers, try desperately to make IPv6 work well on a spare 7200, and hope not to get a black eye from customers who expect the same level of routine-ness we are experienced with in IPv4? Should they provision more circuits because of this? Build a parallel network supporting IPv6, without a current customer demand? Or do they say, "we'll wait until the vendors get it right"? Even if you get past all that, there is still the very obvious fact that for certain vendors, the levels of performance we expect today are because of extensive tuning for IPv4 speed, and we know we won't be seeing this level of performance right off the bat from IPv6. And while they wait, there is no usable IPv6 infastructure, less interest and development from vendors who don't really see a "need", and less demand from users who know there is no point when they can't find a network infastructure to support them. The other problem is IP allocation. ARIN and others are used to their comfortable role as IP Nazi ("No IP for you, come back, one year!"), they have happy extortion-scheme pricing on it, and they're not about to give it up voluntarily any more then NetSol would have without being forced... If you doubt this, go look at the current policies for obtaining IPv6 space. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0