Re: IRR listing of IANA-reserved, a question..
Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person
Re: Network Routing without Cisco or Juniper?
On Wed, Sep 04, 2002 at 03:39:25AM -0400, Deepak Jain wrote: [snip] Boxes like Foundry, Extreme, Redback and many others all talk BGP (at least to a first approximation) but is their lack of use in the core/edge/CPE a lack of scale, stability, performance or just interest? One Dutch ISP that shall remain unnamed (and is not one I work for or have worked for) deployed Extreme on AMS-IX, with Extreme's BGP implementation. It broke horribly. The Extreme BGP implementation, instead of sending their peers just their own prefixes, would send each peer *all* prefixes and then withdraw all but their own networks. However, doing this with tens of peers at the same time was too much for the Extreme itself, which died. Extreme has supposedly fixed this bug, but this ISP switched to Juniper for routing. From what I see around me, Juniper for routing and Extreme for switching is a popular combination. It seems both are considered to be good at one thing and bad at the other. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
RE: IRR listing of IANA-reserved, a question..
http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person
Re: Network Routing without Cisco or Juniper?
On Wed, 4 Sep 2002, Deepak Jain wrote: Boxes like Foundry, Extreme, Redback and many others all talk BGP (at least to a first approximation) but is their lack of use in the core/edge/CPE a lack of scale, stability, performance or just interest? With Extreme, it's certainly (in my experience only) a matter of horrific stability in their routing engine: great switches, truly scary as routers. The thought of BGP on Extreme is almost comedic, considering I'm afraid of their RIP... Yours, J.A. Terranson
Re: Network Routing without Cisco or Juniper?
On Wed, 4 Sep 2002, Deepak Jain wrote: :: Boxes like Foundry, Extreme, Redback and many others all talk BGP :: (at least to a first approximation) but is their lack of use in :: the core/edge/CPE a lack of scale, stability, performance or just :: interest? :: Foundry makes a very good, very stable bgp speaker. I've had them in my network alongside cisco's and juniper's for a couple of years now, and i've never run into any bgp implementation problems that i would consider major. A few annoying bugs here and there, but nothing significantly worse than C or J. Beyond the fact that not too many people are familiar with foundry's gear, I tend to think that foundry has lost face in the service provider world for non-bgp related issues. ACL problems and CAM size issues have come up in really large installs (multi GBps, hundreds of thousands of flows, etc). Foundry is also behind cisco and juniper in features - GRE and netflow/sflow come to mind. The ACL and CAM issues are supposedly fixed in foundry's jetcore chipset boxes, but i haven't seen any of those yet. Sflow is now an option, and from what i hear, their implementation is very very good. Overall, foundry still makes a good box - when you figure in the cost factor, it becomes a great box. I've also played with extreme, but the last i checked, they were *way* behind foundry/cisco/juniper in terms of their bgp stability and feature set. Overall my experience with extreme has not been a pleasant one. I know some people who love them however, so who knows. They seem to make good/fast layer 2 gear, but i've had some scary results with their layer 3 stuff. -jba __ [[EMAIL PROTECTED]] :: analogue.networks.nyc :: http://analogue.net
Re: Network Routing without Cisco or Juniper?
A supplier I don't think I'm at liberty to name. When they were good, they were very, very good. But when they were bad they were horrid. Another supplier I don't wish to name. Mostly worked, but crashed if you made even the slighest configuration change. I'm guessing one of them is Ascend and the other Lucent :-) -- Neil J. McRae - Alive and Kicking [EMAIL PROTECTED]
Re: Network Routing without Cisco or Juniper?
On Wed, 4 Sep 2002, Peter van Dijk wrote: One Dutch ISP that shall remain unnamed (and is not one I work for or have worked for) deployed Extreme on AMS-IX, with Extreme's BGP implementation. It broke horribly. Then again, AMSIX and their Foundry's break every other day as well :) In their case, the while is definately noy more then the sum of their parts :) Paul
Re: Network Routing without Cisco or Juniper?
On Wed, Sep 04, 2002 at 11:35:52AM +0100, Neil J. McRae wrote: A supplier I don't think I'm at liberty to name. When they were good, they were very, very good. But when they were bad they were horrid. Another supplier I don't wish to name. Mostly worked, but crashed if you made even the slighest configuration change. I'm guessing one of them is Ascend and the other Lucent :-) I don't know the first one. You're wrong about the second one. [this bit is drifting offtopic :)] Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: Network Routing without Cisco or Juniper?
On Wed 04 Sep 2002 (11:35 +0100), Neil J. McRae wrote: A supplier I don't think I'm at liberty to name. When they were good, they were very, very good. But when they were bad they were horrid. Another supplier I don't wish to name. Mostly worked, but crashed if you made even the slighest configuration change. I'm guessing one of them is Ascend and the other Lucent :-) No :-) -- Jim Segrave [EMAIL PROTECTED]
Re: IRR listing of IANA-reserved, a question..
Speaking for myself too: I have been wanting an *authoritative* *single* listing of unallocated address space for at least 6 years. Note that this is at a finer granularity than the IANA allocations list and it would have much more frequent changes than the IANA list as address space is allocated to local registries. However it could include a more coarse data set that changes less frequently for those that do not want or need the higher granularity. The only way to make this happen is for the RIRs to collect this data among themselves and publish it regularly. Because of the possible ramifications of errors in this list it is not as simple to do that reliably as it may seem at first glance; but it should be done. I know that the RIRs have efforts underway to publish such authoritative lists. I do not know the exact status of this work. But I fully agree with your requirement for a *single* *authoritative* list. Of course I would use it in the routers I operate. However these are not significant to many peoiple these days. Daniel PS: I do not care at all about the format as long as it is readily machine parseable. Daniel
Re: IRR listing of IANA-reserved, a question..
Daniel, Daniel Karrenberg wrote: Speaking for myself too: [...] I know that the RIRs have efforts underway to publish such authoritative lists. I do not know the exact status of this work. But I fully agree with your requirement for a *single* *authoritative* list. Yes, we at the RIPE NCC are working on such list. However the task, as you said, is not as easy as it seems to be. We have to be confident in the data we publish and this requires some work especially regarding early registrations. There are also efforts by the RIRs to make allocation records more accurate and appearing in the right RIR, the ERX project for instance http://www.arin.net/registration/erx/index.html. Of course I would use it in the routers I operate. However these are not significant to many peoiple these days. Daniel PS: I do not care at all about the format as long as it is readily machine parseable. Daniel Regards, Andrei Robachevsky DB Group Manager RIPE NCC
RE: ATT NYC
BGP is not a bug-free protocol. BGP is the easiest protocol to *debug* when the problem shows up. BGP does not help to accidently affect *unaffected* paths when a problem shows up. While there is a recursion issue in the BGP-IGP scenario, BGP would be just as broke if the only path between two nodes (and whatever nodes are behind them) had their BGP session removed. Misconfigurations do not imply bad network designs. Bugs are bugs (whether they be OSPF or ISIS or BGP). We have seen RSVP/SNMP/NTP/.*P bugs break routers. I also would think that it is a bit of a stretch to criticize the design of the largest networks in the world, which, were it not for bugs here and there, are running just fine. Further, and I think this is what is troubling people here, is how, without IBGP mesh reduction mechanisms, you could build a non-fully meshed network without an IGP and static routes? The only way this is possible is via a combination of meshing, confeds, and route-reflectors, the latter two which are busted by design. If you are building fully meshed networks, then they are small. And one last comment - ISIS is the easiest protocol to troubleshoot IMO. Even RIP is harder because of all the silly holddowns and poison-reverses, etc. BGP is pretty straightforward as well, but there is a lot in the sauce that you need to know from vendor to vendor, etc. With ISIS, you have one DB (or 2), 1 LSP per router, 1 decision point. Finally, you seem to have a problem with dependencies and recursion, philosophically. This surprises me from someone who I know writes code. Do you not use functions? Pointers? What you have said is that a program that breaks because one function relied on another (that failed) is a broken design. My .02 chris It looks like everyone forgot the reason for this discussion to begin with. It is the outage caused by a mistake on a single router that affected parts of the network that were *NOT* affected by the original mess. Please not that this discussion tends to get restarted whenever we have a real OSPF (or ISIS) caused mess. Alex
NANOG 26 Meeting Information
*NANOG 26 Meeting Information* Registration is now open for the 26th Meeting of the North American Network Operators' Group (NANOG). The meeting will be hosted by the University of Oregon and Sprint. The NANOG 26 meeting (October 27-29) will be held back-to-back with the ARIN X meeting (October 30-November 1) at the Eugene Hilton and Conference Center in Eugene, Oregon. Meeting Information: http://www.nanog.org/mtg-0210/index.html Online Registration Form: https://www.merit.edu/nanog/registration.form.html Hotel Information (special NANOG rate expires Oct. 5): http://www.nanog.org/mtg-0210/hotel.html Call for Presentations (deadline September 16): http://www.nanog.org/mtg-0210/call26.html Hope to see you there!
RE: ATT NYC
While there is a recursion issue in the BGP-IGP scenario, BGP would be just as broke if the only path between two nodes (and whatever nodes are behind them) had their BGP session removed. Misconfigurations do not imply bad network designs. Bugs are bugs (whether they be OSPF or ISIS or BGP). In the case on hand, the network had multiple paths to reach outside world. Only one path was affected by misconfiguration. None the less, none of the other paths were used. Since the network statement was missing, the route was gone from IGP. Where is the failover? How could transit customers in Philadelphia and New York be affected by IGP mess in Chicago? I maintain it is caused by one thing and one thing only - bad design. Had this been a BGP route, the other paths would have kicked in just fine, provided that the other paths to the outside world existed. I also would think that it is a bit of a stretch to criticize the design of the largest networks in the world, which, were it not for bugs here and there, are running just fine. Until they break. Again, personally, I would be very pleased to see ATT lose a few million dollars on this, due to the violated SLAs, the same way as UUNET did (and we now know a lot about it, thanks to Worldcom's bankruptcy). If an accidental removal of a network statement in the router config causes such an outage, imagine what kind of problems someone can create by deliberately removing some of those statements? Further, and I think this is what is troubling people here, is how, without IBGP mesh reduction mechanisms, you could build a non-fully meshed network without an IGP and static routes? The only way this is possible is via a combination of meshing, confeds, and route-reflectors, the latter two which are busted by design. If you are building fully meshed networks, then they are small. Confederations, peering between real interfaces, and MEDs. Route-injectors to drop in fixer routes help as well. Finally, you seem to have a problem with dependencies and recursion, philosophically. This surprises me from someone who I know writes code. Do you not use functions? Pointers? What you have said is that a program that breaks because one function relied on another (that failed) is a broken design. I do not have a problem with dependencies and recursion. What I have a problem is the black box implementation of those. The thought of putting a box on a network, putting router ospf 22 into it seeing it up everywhere *scares the living shit* out of me. I am a firm believer in the KISS principal. I am also a firm believer in forcing people to go one extra step to make sure that they *really* want to do certain things. It is more than likely that I would have not had such a strong opinion of existing IGPs (OSPF and ISIS specifically) if those IGPs were following dont tell anyone anything policy until instructed otherwise. Thanks, Alex
Re: IRR listing of IANA-reserved, a question..
We need to be careful, at the RIR level, that data being published doesn't get mucked up. If a RIR publishes a netblock as unallocated and that happens to knock people off the net, then the RIR's need to be willing to solve that problem 7x24x365. Having the IANA, or other entity publishing a list of blocks that have not been allocated to any RIR is much less of a risk, and much less likely to cause operational outage issues. At the RIR level, it would be far more useful to have accurate data on who the registrant / user of the space it. I know the RIR's are working very hard at getting the legacy data in better condition. john brown as a person, and nothing else On Wed, Sep 04, 2002 at 12:46:13PM +0200, Daniel Karrenberg wrote: Speaking for myself too: I have been wanting an *authoritative* *single* listing of unallocated address space for at least 6 years. Note that this is at a finer granularity than the IANA allocations list and it would have much more frequent changes than the IANA list as address space is allocated to local registries. However it could include a more coarse data set that changes less frequently for those that do not want or need the higher granularity. The only way to make this happen is for the RIRs to collect this data among themselves and publish it regularly. Because of the possible ramifications of errors in this list it is not as simple to do that reliably as it may seem at first glance; but it should be done. I know that the RIRs have efforts underway to publish such authoritative lists. I do not know the exact status of this work. But I fully agree with your requirement for a *single* *authoritative* list. Of course I would use it in the routers I operate. However these are not significant to many peoiple these days. Daniel PS: I do not care at all about the format as long as it is readily machine parseable. Daniel
Re: IRR listing of IANA-reserved, a question..
They are not bogus, hence the sub-deligation, and hence a good reason to have a more detailed source of information. I would suspect that this block should be chopped a bit to reflect the IANA/ICANN usage. This block was first routed on the internet via AS 226 around late summer early fall 1999. On Wed, Sep 04, 2002 at 10:08:00AM -0400, David Charlap wrote: John M. Brown wrote: In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Just out of curiosity, do you know that these are bogus source addresses? Some of the IANA-RESERVED block is actually valid and is used by IANA's computers. My company was blocking all of the IANA-RESERVED space for a while, until we discovered that the IANA web server is using an address in that space. Note: $dig www.iana.org a ; DiG 2.0 www.iana.org a ;; -HEADER- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 6, Addit: 6 ;; QUESTIONS: ;; www.iana.org, type = A, class = IN ;; ANSWERS: www.iana.org. 68055 A 192.0.34.69 ... and: $whois -h whois.arin.net 192.0.34.69 IANA RESERVED-192 (NET-192-0-0-0-1) 192.0.0.0 - 192.0.127.255 ICANN c/o Internet Assigned Numbers Authority ICANN (NET-192-0-32-0-1) 192.0.32.0 - 192.0.47.255 Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Again, bogus addresses or legitimate IANA servers? Not everything in IANA-RESERVED is bogus. -- David
Re: IRR listing of IANA-reserved, a question..
On Wed, 04 Sep 2002 10:08:00 -0400 David Charlap [EMAIL PROTECTED] wrote: John M. Brown wrote: In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Just out of curiosity, do you know that these are bogus source addresses? Some of the IANA-RESERVED block is actually valid and is used by IANA's computers. My company was blocking all of the IANA-RESERVED space for a while, until we discovered that the IANA web server is using an address in that space. This seems like an unwise overlaying of the IANA-RESERVED space to me. Why can't IANA allocate itself a /20 (or whatever it needs) and keep IANA-RESERVED space for unallocated addresses (plus maybe experimental uses that can and should be filtered at every border). Regards Marshall Eubanks that Note: $dig www.iana.org a ; DiG 2.0 www.iana.org a ;; -HEADER- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 6, Addit: 6 ;; QUESTIONS: ;; www.iana.org, type = A, class = IN ;; ANSWERS: www.iana.org. 68055 A 192.0.34.69 ... and: $whois -h whois.arin.net 192.0.34.69 IANA RESERVED-192 (NET-192-0-0-0-1) 192.0.0.0 - 192.0.127.255 ICANN c/o Internet Assigned Numbers Authority ICANN (NET-192-0-32-0-1) 192.0.32.0 - 192.0.47.255 Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Again, bogus addresses or legitimate IANA servers? Not everything in IANA-RESERVED is bogus. -- David
Re: Network Routing without Cisco or Juniper?
On Wed, 4 Sep 2002 05:30:46 -0400 (EDT), jeffrey.arnold [EMAIL PROTECTED] said: Foundry makes a very good, very stable bgp speaker. I've had them in my network alongside cisco's and juniper's for a couple of years now, and i've never run into any bgp implementation problems that i would consider major. A few annoying bugs here and there, but nothing significantly worse than C or J. Thinking of it, I want to confirm, although we have only really used IBGP (including IMBGP, and doing MD5 authentication) and OSPF on those (please, no flames that you only need either of those :-). In this respect the Foundries have never been problematic, and I noticed they learned the full routing table much faster than our (old) C's upon startup. The only problem we had was that in our deployment we really needed MBGP, and that became available much later than originally announced. But when it came it instantly worked as advertised, at least as far as we tried. Beyond the fact that not too many people are familiar with foundry's gear, I tend to think that foundry has lost face in the service provider world for non-bgp related issues. ACL problems and CAM size issues have come up in really large installs (multi GBps, hundreds of thousands of flows, etc). Foundry is also behind cisco and juniper in features - GRE and netflow/sflow come to mind. My main problem is that I find debugging protocol operation (such as PIM-SM) much more difficult than on Cisco. And you can't expect them to have as many resources to develop new fatures all the time; and the ones that get the resources may not be those that are interesting to ISPs. The ACL and CAM issues are supposedly fixed in foundry's jetcore chipset boxes, but i haven't seen any of those yet. Sflow is now an option, and from what i hear, their implementation is very very good. Overall, foundry still makes a good box - when you figure in the cost factor, it becomes a great box. Definitely agree. Also they start up incredibly fast, because the software is so small. So upgrading software on the box is relatively painless. -- Simon.
RE: Network Routing without Cisco or Juniper?
I'm a big fan of both Foundry and Riverstone, as BGP speaking routers. I've had great luck with both. Foundry has some annoying bugs at first, but these seem to have been resolved. I recommend both. - Daniel Golding On Wed, 4 Sep 2002, Deepak Jain wrote: :: Boxes like Foundry, Extreme, Redback and many others all talk BGP :: (at least to a first approximation) but is their lack of use in :: the core/edge/CPE a lack of scale, stability, performance or just :: interest? :: Foundry makes a very good, very stable bgp speaker. I've had them in my network alongside cisco's and juniper's for a couple of years now, and i've never run into any bgp implementation problems that i would consider major. A few annoying bugs here and there, but nothing significantly worse than C or J. Beyond the fact that not too many people are familiar with foundry's gear, I tend to think that foundry has lost face in the service provider world for non-bgp related issues. ACL problems and CAM size issues have come up in really large installs (multi GBps, hundreds of thousands of flows, etc). Foundry is also behind cisco and juniper in features - GRE and netflow/sflow come to mind. The ACL and CAM issues are supposedly fixed in foundry's jetcore chipset boxes, but i haven't seen any of those yet. Sflow is now an option, and from what i hear, their implementation is very very good. Overall, foundry still makes a good box - when you figure in the cost factor, it becomes a great box. I've also played with extreme, but the last i checked, they were *way* behind foundry/cisco/juniper in terms of their bgp stability and feature set. Overall my experience with extreme has not been a pleasant one. I know some people who love them however, so who knows. They seem to make good/fast layer 2 gear, but i've had some scary results with their layer 3 stuff. -jba __ [[EMAIL PROTECTED]] :: analogue.networks.nyc :: http://analogue.net
Re: follow-up IANA-RESERVED IRR
Cool, maybe we're making progress. The last N times this has come up, the biggest X the big IP backbones showed a distinct lack of interest or in one case extreme hostility to the idea. I've suggested an AS-NULL(AS0) or AS-RESERVED machine parsable macros for unassigned prefixes which should have no routes (including more specific routes) which could be automatically included in router configurations. Or at least queried when debuging stuff. Every network block should be assigned an responsible party. I'm avoiding using the word owner. By default IANA would be the responsible party for all RESERVED address space, and listed as such in IANA, RIR, or where ever we decied to keep the information. As address space is assigned, allocated, delegated, etc, the reserved space would be split so you can tell the difference between address squaters and valid assignments. RESERVED (Not released by IANA for use) ALLOCATED (Available for network allocations, but not in use) ASSIGNED (Assigned for use by an entity, may be routed now or soon) CONNECTED (Connected to the global Internet) MULTICAST (Not a valid source address) SPECIAL (Matians, we don't know where they come from, drop on sight) EXPERIMENTAL (Consenting parties only) PRIVATE (Local use only) On Wed, 4 Sep 2002, John M. Brown wrote: A good number of private replies from people and their day job addresses. Most have asked for prior permission before quoting them. In general, three default-free global backbone providers stated they would love to see something like this available, from IANA is the prefered answer. Some would like to see more than just IANA address information, and other contend that would be a can of worms and opens some risk issues. It seems that there is general support and that people would use such a service if available and reliable. If you have comments on this, and can post publicly, please do. Thank you john brown speaking for himself
Re: follow-up IANA-RESERVED IRR
I'm concerned with having to much data in the system. This invites mistakes, potential abuse and other problems. By having only: RESERVED or ALLOCATED and having that publishd by IANA, we reduce the potential of mistakes affecting real users. If the RIR's are going to provide more data, then they need to upgrade their business and expense models to support live people 7x24x365 so that mistakes are fixed QUICKLY. Just my own personal $.02 on the topic. I would suggest, crawl, walk, run with this idea. Lets first get IANA up and going, then see how well that works and move forward if it makes sense and the appropriate protections can be in place. john brown speaking for himself only On Wed, Sep 04, 2002 at 02:34:27PM -0400, Sean Donelan wrote: Cool, maybe we're making progress. The last N times this has come up, the biggest X the big IP backbones showed a distinct lack of interest or in one case extreme hostility to the idea. I've suggested an AS-NULL(AS0) or AS-RESERVED machine parsable macros for unassigned prefixes which should have no routes (including more specific routes) which could be automatically included in router configurations. Or at least queried when debuging stuff. Every network block should be assigned an responsible party. I'm avoiding using the word owner. By default IANA would be the responsible party for all RESERVED address space, and listed as such in IANA, RIR, or where ever we decied to keep the information. As address space is assigned, allocated, delegated, etc, the reserved space would be split so you can tell the difference between address squaters and valid assignments. RESERVED (Not released by IANA for use) ALLOCATED (Available for network allocations, but not in use) ASSIGNED (Assigned for use by an entity, may be routed now or soon) CONNECTED (Connected to the global Internet) MULTICAST (Not a valid source address) SPECIAL (Matians, we don't know where they come from, drop on sight) EXPERIMENTAL (Consenting parties only) PRIVATE (Local use only) On Wed, 4 Sep 2002, John M. Brown wrote: A good number of private replies from people and their day job addresses. Most have asked for prior permission before quoting them. In general, three default-free global backbone providers stated they would love to see something like this available, from IANA is the prefered answer. Some would like to see more than just IANA address information, and other contend that would be a can of worms and opens some risk issues. It seems that there is general support and that people would use such a service if available and reliable. If you have comments on this, and can post publicly, please do. Thank you john brown speaking for himself
Re: follow-up IANA-RESERVED IRR
RESERVED or ALLOCATED and having that publishd by IANA, we reduce the potential of mistakes affecting real users. Actually, this was part of the original RAdb. All the RESERVED space was mapped to AS-0. This was not considered useful and it was dropped. Cisco (and perhaps others), co-opted AS-0 for their own nefarious purposes.
RE: IRR listing of IANA-reserved, a question..
Yes. 256 lines is probably better, just to make it easily portable. Also I'd like to see the list of how the ips are split between reginal registries for whois purposes. For example blocks like 3.0.0.0/8 or 4.0.0.0/8 have records in ARIN. I think therefore they should be listed as ARIN blocks even if they are used entirely by one company. What I'd like to see if format like this: block registrydate of allocation comment (purpose) And additional list which has list of all ip registries and contact info for each one include website, whois server, etc. I also would like to see ICANN can put all /8 (its only 256 records) in its whois server and have this information available there as well. On Wed, 4 Sep 2002, John Crain wrote: http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person -- William Leibzon Elan Communications Inc.
RE: IRR listing of IANA-reserved, a question..
Actually let me correct myself... The format I think would be better is: block date-of-current-allocation registrycomment/purpose I don't want to see separate lines below like (Formerly Stanford University - Apr 93). This should be part of the comment on the same line and date should always be the last change, i.e. 049/8 Joint Technical Command May 94 Returned to IANAMar 98 should actually be: 049/8 Mar98 IANAFormerly Joint Technical Command (May 94 - Mar 98) On Wed, 4 Sep 2002 [EMAIL PROTECTED] wrote: Yes. 256 lines is probably better, just to make it easily portable. Also I'd like to see the list of how the ips are split between reginal registries for whois purposes. For example blocks like 3.0.0.0/8 or 4.0.0.0/8 have records in ARIN. I think therefore they should be listed as ARIN blocks even if they are used entirely by one company. What I'd like to see if format like this: block registrydate of allocation comment (purpose) And additional list which has list of all ip registries and contact info for each one include website, whois server, etc. I also would like to see ICANN can put all /8 (its only 256 records) in its whois server and have this information available there as well. On Wed, 4 Sep 2002, John Crain wrote: http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person
Re: follow-up IANA-RESERVED IRR
On Wed, 4 Sep 2002, John M. Brown wrote: I'm concerned with having to much data in the system. This invites mistakes, potential abuse and other problems. By having only: RESERVED or ALLOCATED I'm ok with anything, as long as we try to move in the forward direction. BTW, IANA needs to remember to ALLOCATE addresses used by themselves. One problem with the current system is its difficult to tell when you have a squatter announcing a more specific block, or if it has really been allocated to them. Sean Doran demonstrated this many years ago. and having that publishd by IANA, we reduce the potential of mistakes affecting real users. Actually we don't reduce the potential for mistakes. It just makes it easier to track down the culprits. If the RIR's are going to provide more data, then they need to upgrade their business and expense models to support live people 7x24x365 so that mistakes are fixed QUICKLY. Just my own personal $.02 on the topic. I would suggest, crawl, walk, run with this idea. Lets first get IANA up and going, then see how well that works and move forward if it makes sense and the appropriate protections can be in place. Go for it. I've already submitted my recommendations on the new US national cyberprotection plan to the US Government. I don't know if they'll choose any of my ideas. I would much prefer to see a group of Internet engineers solve the problem. We've been talking about it since 1995. Instead the proposed technical solutions keep getting more and more complex to avoid dealing with the real problem. I think the actual solution is much simplier, but requires cooperation from at least the largest ISPs, RIRs and IANA. Yes, it requires more work, but its a lot less complex than some of the other ideas I've seen recently.
RE: IRR listing of IANA-reserved, a question..
List the 128-191/8 allocations first. Getting this information from the RIR's has been tedious. After that, details on each /8 for all 256 lines would be useful. It is a stepping stone to some of other suggestions that are bound to come out of this thread. Rob Thomas and I have been playing around with a more stricter ingress prefix filter template to help ISPs get out of the I only filter RFC1918 rut. You can check out the drafts at: http://www.cisco.com/public/con/isp/security/ The big question was a consensus on how to handle a template recommendation for the old B space and C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Crain Sent: Wednesday, September 04, 2002 1:04 AM To: 'Jeffrey Meltzer'; [EMAIL PROTECTED] Subject: RE: IRR listing of IANA-reserved, a question.. http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person
RE: IRR listing of IANA-reserved, a question..
Whoops that should be http://www.cisco.com/public/cons/isp/security/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Barry Raveendran Greene Sent: Wednesday, September 04, 2002 1:29 PM To: John Crain; 'Jeffrey Meltzer'; [EMAIL PROTECTED] Subject: RE: IRR listing of IANA-reserved, a question.. List the 128-191/8 allocations first. Getting this information from the RIR's has been tedious. After that, details on each /8 for all 256 lines would be useful. It is a stepping stone to some of other suggestions that are bound to come out of this thread. Rob Thomas and I have been playing around with a more stricter ingress prefix filter template to help ISPs get out of the I only filter RFC1918 rut. You can check out the drafts at: http://www.cisco.com/public/con/isp/security/ The big question was a consensus on how to handle a template recommendation for the old B space and C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Crain Sent: Wednesday, September 04, 2002 1:04 AM To: 'Jeffrey Meltzer'; [EMAIL PROTECTED] Subject: RE: IRR listing of IANA-reserved, a question.. http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person
RE: IRR listing of IANA-reserved, a question..
List the 128-191/8 allocations first. Getting this information from the RIR's has been tedious. Unless IANA was responsible for those initial allocations, it should not be IANA's task to make this list. And if IANA makes such a list I think it should be separate from the /8 list presented at http://www.iana.org/assignments/ipv4-address-space I'd much rather have regional registries list information for customers for all blocks for companies that are located in their territory. And that means information for initial allocations made prior to APNIC/RIPE should be moved to those registraries with link available from ARIN. All those /8 which IANA currently lists as having multiple registries are in reality in ARIN's database currently so we might as well consider ARIN to be responsible registry, however in case where majority of allocations in that block are going to custoers in other region, IANA should consider having another RIR be made reponsible for that /8 block. My opinion is that we have chosen right approach by having a heirchy of responsibilities for ip allocations, i.e. IANA-RIR-ISP-customer. We should try to keep to this strategy and for old records have the information transfered to approriate authority. IANA should only keep records for entire /8 in the end. After that, details on each /8 for all 256 lines would be useful. It is a stepping stone to some of other suggestions that are bound to come out of this thread. Rob Thomas and I have been playing around with a more stricter ingress prefix filter template to help ISPs get out of the I only filter RFC1918 rut. You can check out the drafts at: http://www.cisco.com/public/con/isp/security/ The big question was a consensus on how to handle a template recommendation for the old B space and C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Crain Sent: Wednesday, September 04, 2002 1:04 AM To: 'Jeffrey Meltzer'; [EMAIL PROTECTED] Subject: RE: IRR listing of IANA-reserved, a question.. http://www.iana.org/assignments/ipv4-address-space If folks want me to split it to show 256 lines (one per /8) I can have that happen. Don't want to have multiple sources of the data, so for now that's probably easiest. I'll watch this discussion with interest. If people think something is useful at the IANA level I'll do my best to make it happen. _ John Crain Manager of Technical Operations ICANN [EMAIL PROTECTED] 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Meltzer Sent: Tuesday, September 03, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: IRR listing of IANA-reserved, a question.. Wouldn't the easiest (at least short term) thing be for IANA (or someone else authoritative-like) to put up a text file (not that I'm really sure how many blocks this entails) available via http or ftp for people to periodically wget, etc. Surely IANA, ARIN, or someone else has some type of up-to date database that they could script, etc to generate this file? On Tue, Sep 03, 2002 at 06:36:04PM -0700, John M. Brown wrote: First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such special use or reserved prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a
RE: IRR listing of IANA-reserved, a question..
On Wed, 4 Sep 2002 [EMAIL PROTECTED] wrote: List the 128-191/8 allocations first. Getting this information from the RIR's has been tedious. Unless IANA was responsible for those initial allocations, it should not be IANA's task to make this list. And if IANA makes such a list I think it should be separate from the /8 list presented at http://www.iana.org/assignments/ipv4-address-space Originally IANA (Postel) allocated all the numbers. So if its old enough, or special enough like the Cable net 24, it originally came from IANA. But who really cares if it originally was allocated by IANA? Over the years, parts of blocks have been allocated by different groups. In some cases part of the allocations in a network range were originally done by one group, and part way throug the range the maintenance was transfered to a different organization (e.g. maintenance of the 24 block was transfered to ARIN). At the simiplest, figuring out who did what when is still a mess. But we do NOT need to answer that question. If an address block has NOT been allocated by IANA, it should NEVER appear in the global Internet routing table exchanged between ISPs. To make that a positive statement, according to IANA has block X been allocated for unicast routing purposes? We don't need to know who, where, when, why. Just what. Net/8 Allocated for unicast routing on Internet 0/8 N 1/8 N 2/8 N 3/8 Y 4/8 Y ... 10/8N ... 127/8 N ... 224/8 N ... 255/8 N I know, what about multicast, what about Class E addresses, what about addresses allocated by IANA but not by the RIR, ... All great questions. People want this information so they can filter their BGP routing tables. What addresses are legal (following the liberal in what you accept, conservative in what you send motto) for the global Internet BGP routing table. As a first cut let's document, preferably in a machine readable form for easy updating, what are the network blocks allocated for use.
Equinix and Big 7??
The latest Cooke Report made the following statement: They are, he says, the Internet Core Networks that announced anonymously on December 5, 2001 their decision to move their peering to Equinix Exchanges. He identifies them as UUNET, Sprint, Cable and Wireless, Genuity, Level 3, Qwest, and ATT. I was wondering if anyone could verify these seven networks moving their collective peering to Equinix and if so any specifics. Previous posts in the archive on participants at Equinix do not seem to bear this out. Any feedback is greatly appreciated. Thanks, sean
RE: Network Routing without Cisco or Juniper?
I have to second that. Riverstone is definitely a solid box. Featurewise, routing protocols are excellent, but services are not quite there. (I.E. it doesn't support any IP tunneling protocol in any shape or form. GRE is extremely useful under some circumstances, but sadly, not with riverstone). On Wed, 4 Sep 2002, Derek Samford wrote: Another box I personally feel is very overlooked is Riverstone. They make an excellent box, the CLI is incredible (especially for maintenance windows. When will Cisco learn to have a Scratchpad or a commit feature?), and all-in-all they are a very feature rich box. The only *major* problem I had to do with BGP actually was a fault of their being RFC-Compliant. I believe this was about a year ago, they dropped the peer on a bogus prefix, that was being carried throughout the net (Originating from a Qwest client if I remember correctly.) Then again, I believe this affected more vendors than just RS.
RE: IRR listing of IANA-reserved, a question..
On Wed, 4 Sep 2002 [EMAIL PROTECTED] wrote: I used the list posted at iana and created the list in the what I think is better for use by own whois server. Its likely to be of use to others. Also based on suggestion by Sean Donelan column has been added if /8 block is or should be routable or not (my own opinion). The list is available at http://www.completewhois.com/iana-ipv4-addresses I'm also posting it here below (you're free to modify or not and use it for whatever purposes you desire): 92 /8s reserved... Since the start of 1999, ARIN has grown by 6 /8s, APNIC and RIPE by 4 each, for a total of 14 /8s in almost 4 years. Call it an even /4 per 4 years, for an average of a /6 per year. Now, assume some acceleration in growth...say global assignment increases to /7 per year starting next year, which I think is unreasonable but illustrative for the sake of the point. That would still provide space for the next 10+ years. And looking at the list, there are still several companies who have unreasonable allocations. You have weird things like Eli Lilly and Company, Ford, US Postal Service, Prudential Securities, Interop Show Network, Halliburton Company, Apple, Xerox, Computer Sciences Corporation, etc. I'm sure these companies have legitimate needs for large amounts of address space, but they most likely don't even need a /8 combined. Surely the US-DOD (with 10 /8s to their name) would like to renumber into rfc1918 space for a myriad of reasons. If not, one would think that can be reduced considerably. This is all ignoring the considerable amount of dead space in 128/2. Does anybody keep statistics about what percentage of useable space is announced? So...my question is, without a marketable product, and without a need for the considerable future, will IPv6 remain a barely supported protocol for too long to be implemented? Will IPv6 be surpassed by a superior protocol before it becomes neccessary to be implemented? 10 years is a long time... Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
