Re: Transition Planning for IPv6 as mandated by the US Govt
Randy Bush wrote: And the NAT-PT implementation at NANOG (naptd) did seem to work once some configuration issues were ironed out. Unfortunately, this was not resolved until the very end of the meeting. your made heroic efforts with the linux nat-pt, and finally got it. but do you think it will scale well? For the size of a NANOG meeting, it seemed to be sufficient. I don't think I'd recommend trying to put thousands of users behind it though. i suspect that all the nat-pt implementations are old and not well maintained. this needs to be fixed. Still trying to understand deployment scenarios for nat-pt. I could see a case for very controlled environments with uniform clients (with robust v6 support). Outside of that, native-v6 + v4-nat (as outlined in Michael Sinatra's lightning talk) and Alain Durand's v4v6v4 seem more likely deployment candidates. That said, nat-pt is very useful for exercising native v6 support in clients and their applications. -Larry
Re: Transition Planning for IPv6 as mandated by the US Govt
Randy Bush wrote: I believe whoever shows off a functional NAT-PT device at the next NANOG might get some praise. I heard it was a bit of a disaster. by the time the show got to apnic/apricot the week after nanog, we had the cisco implementation of nat-pt and totd working and it worked well. randy And the NAT-PT implementation at NANOG (naptd) did seem to work once some configuration issues were ironed out. Unfortunately, this was not resolved until the very end of the meeting.
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
Suresh Ramasubramanian wrote: On Mon, Mar 17, 2008 at 6:38 PM, Jeff Aitken <[EMAIL PROTECTED]> wrote: IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented. Start with "implement RFC 2827 yourself, and start pushing other SPs to implement it" maybe? srs RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across any RFC's with a thorough discussion of route filtering. It is mentioned briefly in RFC 3013, but section 4.5 only suggests filtering routes for private address space. RFC 4778 also mentions it, but again, there is no in depth discussion. Perhaps it is time for an RFC dedicated to route filtering practices? -Larry Blunk Merit
Re: load balancing and fault tolerance without load balancer
You might want to consider client side load balancing -- http://www.digital-web.com/articles/client_side_load_balancing/ Joe Shen wrote: hi, we plan to set up a web site with two web servers. The two servers should be under the same domain name. Normally, web surfing load should be distributed between the servers. when one server fails, the other server should take all of load automatically. When fault sever recovers, load balancing should be achived automatically.There is no buget for load balancer. we plan to use DNS to balance load between the two servers. But, it seems DNS based solution could not direct all load to one server automatically when the other is down. Is there any way to solve problem above? we use HP-UX with MC-Service Guard installed. thanks in advance. Joe
Re: RADB down?
Apologies for the issues. We had a switch failure last night and while a replacement switch is now in place, there are still a few transition issues being resolved. -Larry Blunk Merit John van Oppen wrote: Yep, works from my other desk machine... Same subnet, different IP as well. I note it appears to be breaking their web whois queries as well as I get a "connect failed: Connection timed out" notice on any of the webform updates. John -Original Message- From: Mike Tancsa [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2008 11:04 AM To: John van Oppen; nanog@merit.edu Subject: Re: RADB down? At 01:52 PM 3/5/2008, John van Oppen wrote: Anyone else seeing the radb whois server as being down? Simple whois seems to work ok for me from one IP address, but not from another on the same subnet... % ping -S 199.212.134.1 whois.ra.net PING whois.radb.net (198.108.0.18) from 199.212.134.1: 56 data bytes ^C --- whois.radb.net ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ping -S 199.212.134.2 whois.ra.net PING whois.radb.net (198.108.0.18) from 199.212.134.2: 56 data bytes 64 bytes from 198.108.0.18: icmp_seq=0 ttl=56 time=25.556 ms 64 bytes from 198.108.0.18: icmp_seq=1 ttl=56 time=25.886 ms ^C --- whois.radb.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 25.556/25.721/25.886/0.165 ms # whois -h whois.ra.net AS11404 aut-num:AS11404 as-name:VOBIZ descr: vanoppen.biz LLC / Spectrum Networks LLC member-of: AS-VOBIZ import: from AS2914 accept ANY import: from AS3491 accept ANY import: from AS3356 accept ANY export: to AS2914 announce AS-VOBIZ export: to AS3491 announce AS-VOBIZ export: to AS3356 announce AS-VOBIZ admin-c:John van Oppen tech-c: John van Oppen mnt-by: MAINT-AS11404 changed:[EMAIL PROTECTED] 20070401 #16:20:39(UTC) changed:[EMAIL PROTECTED] 20070903 #17:42:34(UTC) changed:[EMAIL PROTECTED] 20080125 #07:55:53(UTC) source: RADB # traceroute -s 199.212.134.2 -q1 198.108.0.18 traceroute to 198.108.0.18 (198.108.0.18), 64 hops max, 44 byte packets 1 iolite4-fxp2 (199.212.134.10) 0.126 ms 2 cogent-vl108 (67.43.129.246) 2.950 ms 3 gi8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 2.975 ms 4 vl3492.mpd01.yyz01.atlas.cogentco.com (154.54.5.81) 3.355 ms 5 te8-2.mpd01.ord01.atlas.cogentco.com (154.54.7.73) 18.345 ms 6 vl3489.mpd01.ord03.atlas.cogentco.com (154.54.5.18) 17.938 ms 7 Merit.demarc.cogentco.com (66.28.21.234) 18.053 ms 8 ge-0-2-0x43.aa1.mich.net (198.108.22.241) 27.641 ms 9 rpsl-p.merit.edu (198.108.0.18) 31.018 ms % traceroute -n -q1 198.108.0.18 traceroute to 198.108.0.18 (198.108.0.18), 64 hops max, 40 byte packets 1 199.212.134.10 0.180 ms 2 67.43.129.246 3.220 ms 3 38.104.158.77 3.977 ms 4 154.54.5.85 7.361 ms 5 154.54.2.161 18.714 ms 6 154.54.25.66 18.852 ms 7 38.112.7.10 20.107 ms 8 198.108.22.241 30.215 ms 9 * 10 * Bad Load balancer or busted MPLS silliness or firewall issue ? ---Mike
Re: NANOG 40 agenda posted
Chris L. Morrow wrote: On Tue, 29 May 2007, Iljitsch van Beijnum wrote: # traceroute6 www.nanog.org traceroute6: hostname nor servname provided, or not known That would be a start... It took years to get the IETF to eat its own dog food, though. i suspect the merit/nanog folks involved with the server(s) could probably hook up a way for that to actually work... I'd even volunteer an apache reverse proxy in v6-land if it'd help. A v6 server is now up at www.ipv6.nanog.org. As a bonus incentive, you get to see the Merit mascot (no, it's not a dancing turtle).Unfortunately, there's some unresolved issues with the secure registration server, so we can't add an record for www.nanog.org yet. -Larry Blunk Merit
Re: soBGP deployment
On Mon, 2005-05-23 at 10:11 -0400, Randy Bush wrote: > > If you look back to the NSFNet days (prior to a decade ago) and > > the PRDB (Policy Routing Database), you might very well draw a > > different conclusion. > > indeed, one of utter disaster. it would take days or weeks > before one could route a prefix. > I suspect this was due to the fact that template submissions were not fully automated at the time and required human review (disclaimer: I worked for the MichNet side of Merit back then and was not intimately familiar with PRDB operations). -Larry
Re: soBGP deployment
On Sat, 2005-05-21 at 16:03 -0400, Steven M. Bellovin wrote: > Look at it this way: do you think that (a) most > sites will publish their policies in the registry, and (b) they'll > remember to update them? As Randy has noted, we have a decade of > experience suggesting that neither is true. > There's a very simple reason why registries have not been kept up to date over the past decade -- many operators do not use them for generating their policy configurations. Given this situation, it's difficult to draw any conclusions from the last decade. If you look back to the NSFNet days (prior to a decade ago) and the PRDB (Policy Routing Database), you might very well draw a different conclusion. The PRDB was kept up to date because a database entry was required to transit the NSFNet. This is not to imply that registries should play anything more than an interim role. Nonetheless, there would seem to be opportunities to improve current operational practices until more secure solutions are deployed. -Larry Blunk Merit
Re: Traceroute with ASN
On Tue, 2005-03-15 at 15:03 -0800, Bruce Pinsky wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brett Watson wrote: > | On 3/15/05 3:11 AM, "Ziggy David Lubowa" <[EMAIL PROTECTED]> wrote: > | > | > |> > |>On Tue, 15 Mar 2005 17:51:32 +0800 (CST), Joe Shen wrote > |> > |>>Yes. Can I do this on a Linux box without having to > |>>install Zebra BGP on it? > |> > |>Doesnt look like you have to, below is the link to the tarball > |> > |>http://oppleman.com/dl/?file=lft-2.3.tar.gz > | > | > | I believe the author of LFT is working on a new release that does *not* use > | the oft-times incorrect radb data, but instead pulls from a router (not sure > | of the source) somewhere. > | > > Would probably be nice to have a command-line option to specify the source > from either: > > - - an RADB formatted source > - - a Zebra or Quaaga BGP daemon > - - via SNMP from a BGP capable device A 4th option would be the Routeviews DNS based mapping service at asn.routeviews.org. See -- http://www.merit.edu/mail.archives/nanog/2003-09/msg00832.html An advantage here is that you get caching for free.
Re: High volume WHOIS queries
On Tue, 2005-03-01 at 16:40 -0600, Jeff Bartig wrote: > > > On 2/28/05 1:30 PM, "Dan Lockwood" <[EMAIL PROTECTED]> wrote: > > > > > > > > I'm in a disagreement with ARIN about my application for bulk whois > > > data. I've got a software program that needs resolve AS numbers to the > > > Company Name of the owner. The software app has need to do this on a > > > very high volume. E.g. I run a report that returns the top 100 AS > > > destinations for my network and I want to resolve the numbers to the > > > names as part of the report generation. Since ARIN throttles the number > > > of queries that you can execute against their servers I seems to "just > > > make sense" that you would do the processing using local data. > > Not exactly what you are looking for, but how about > > ftp://ftp.arin.net/info/asn.txt > > Lists AS number, the whois AS name, and POC handle for each AS. > > Jeff > If you are also interested in AS info outside the ARIN region, the following file may be of interest -- http://bgp.potaroo.net/as1221/asnames.txt -Larry
Re: RADB question
On Wednesday 24 November 2004 14:21, Paul Ryan wrote: > Just a quick question regarding RADB - how are you guys dealing with abuse > complaints sent to the "radb-notify" or "radb-maint" e-mail addresses. I > have some ideas but wanted to get a concensus from the commmunity ... > > Thoughts anyone ? > > Regards, > > Paul Actually, we've been considering adding a privacy feature to mangle/hide these email addresses. We already do something similar with the CRYPT-PW password hashes to prevent password cracking. If folks feel this is important, we could up it on the priority list. -Larry Blunk Merit
RE: Hijacked IP space.
On Tue, 2003-11-04 at 10:51, Randy Bush wrote: > > Those options are not mutually exclusive, and, while I agree that > > it would be better if the RIR's accepted generic GPG keys along > > the lines of what RADB does, the X.509 certificate is not a bad > > first step. At least it's better than Mail-From or Crypt-PW. > Should we, as a community, register with RIR's with PGP. > >>> Each of the RIRs has either already established, or is in the > >>> process of establishing, a CA for that purpose. Please use > >>> them. > >> thanks, but i choose to have my peers certify my identity, not the > >> rirs > > the rirs already accept pgp certs. and i use them, as do all > security-conscious registrants. i was disagreeing with woody's > pushing x.509 certs to the exclusion of pgp certs. > > randy > --- I would note that the RIPE NCC, while implementing X.509 support, is moving away from the concept of running their own CA. Their X.509 support will be very "PGP-like". See the following for details - http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-x509.pdf
Re: RADB
Christopher, I suspect the "route" objects that one would typically register in the RADB or other routing registries is generally a small subset of the "networks" one would register in their rwhois server. The route objects should consist of only those prefixes which are announced via BGP and not the more specifics which are assigned to customers (but not announced by them). You would need to somehow tag those network prefixes which correspond to announced routes and also devise a mechanism to specify the origin AS (a required field in the RPSL route object). If you'd like to discuss this further, I'd suggest we move this to [EMAIL PROTECTED] rather than spending additional NANOG bandwidth on it (and if there is any other interest out there, please feel free to let us know at this address as well). Regards, Larry J. Blunk Merit On Wed, 2003-09-24 at 15:13, Christopher J. Wolff wrote: > Hello, > > On the RADB site, under features and benefits, the service claims to mirror > "more than 30 other IRR databases." > > My challenge is that I need to list my information with RADB and don't want > to go through the hassle of manually submitting every subnet owner and > first-born when I can put a RWHOIS server up for ARIN. RADB should just > poll my RWHOIS server. > > Thank you in advance for your advice. > > Regards, > Christopher J. Wolff >
Re: State Super-DMCA Too True
> Larry J. Blunk wrote: > > > >I'm not trying to justify allowing the use of NAT where it is > > prohibited by a terms of service agreement and thus grounds for > > termination of service. However, going beyond termination of > > service and making this an illegal act under law (possibly > > punishable by a felony conviction and 4 years in prison) is an > > entirely different case. If you stop paying your ISP bill > > (thus getting several months for free until the ISP cuts you > > off) wouldn't that also be theft of service? Should one > > also be subject to a felony conviction and 4 years of prison for > > such an act? > > If it takes a few months for the ISP to cut you off for not paying your > bill, that is their own fault. Concerning someone going to jail for > running NAT in breach of TOS, I find it supportable. There is precedence > set with the Cable companies (using equipment to allow service to be > used on more than tv's than allowed by the cable company would be > equivelent here). > > -Jack Sigh. My point is this is a question of extremes and punishment commensurate with the "crime". I can understand how one could consider NAT to be "theft" under a terms of service agreement. I can even understand how one might think this should be a criminal offense (although I would disagree - consider how many ISP's consider NAT to be perfectly acceptable). However, going beyond a misdemeanor offense and a fine - advocating prison time and felony convictions - is something I simply can't understand or find supportable.
Re: State Super-DMCA Too True
> On Sun, Mar 30, 2003 at 03:58:17AM -0500, Larry J. Blunk wrote: > >The problem is that these laws not only outlaw the use of NAT devices > > where prohibited, but also the sale and possession of such devices. > > Futher, I think many would disagree that the use of NAT where prohibited > > necessarily should be considered an illegal activity. Note that the > > customer is still paying for a service, so the question of "theft" > > is debatable. It is one thing for an ISP to terminate service for > > breach of contract by using a NAT device, it is quite something > > else to put someone in prison for such a breach. > > I really fail to see what the problem is. > You're trying to justify that you should be allowed to use NAT (and by > implication, mulitple nodes behind your NAT) and it not be illegal. > If your ISP says that you are paying for access *per node* and not > allwoedto use NAT, then your use of NAT is theft of service, because > you're not paying for those extra nodes to access (through) the ISP's > network. > The extra cost (or lack there of) to the ISP is irrelevent. If you're > not allwoed to use NAT, you're not allowed to use NAT. > If you're paying for per-node access, breach of this is theft of > service. I'm not trying to justify allowing the use of NAT where it is prohibited by a terms of service agreement and thus grounds for termination of service. However, going beyond termination of service and making this an illegal act under law (possibly punishable by a felony conviction and 4 years in prison) is an entirely different case. If you stop paying your ISP bill (thus getting several months for free until the ISP cuts you off) wouldn't that also be theft of service? Should one also be subject to a felony conviction and 4 years of prison for such an act? > > >I found one large broadband provider in Michigan that prohibits > > the use of NAT devices -- Charter Communications. Comcast, Verizon, > > and SBC seem to allow them for personal household use (although they > > do have value-add services that charge extra for multiple routable static > > IP addresses). > > Interesting that Charter Communications in Los Angeles doesn't mind you > doing this. Here is my reference for Charter Communications in Michigan, however, this web page could be out of date. http://support.chartermi.net/gh/residential/pipeline/ Additional Computers: Charter Communications allows up to 3 computers behind each cable modem connected via a hub. The customer is responsible for the purchase and installation of the hub, cross over cables and ethernet cables necessary to connect the additional computers. Charter Communications does not support or install hubs or additional computers. Charter prohibits the use of routers or proxy servers behind cable modems. Use of these methods to connect additional computers and Local Area Networks is grounds for disconnection of service. For more than 3 computers or for a Local Area Networks please speak to our Commercial Sales Team: 888-968-3442.
Re: State Super-DMCA Too True
> > Not true. An ISP can choose to allow NAT and wireless or not allow it. > This is the ISPs choice. The law is designed to protect the ISPs rights > from existing technology so that the ISP can bill appropriately > according to what service is being used. This does not mean that every > ISP will not allow NAT. > > > (Some DSL/cable companies try to charge per machine, and record the > > machine address of the devices connected.) > > And to use NAT to circumvent this should be illegal. It is theft of > service. The ISP has the right to setup a business model and sell as it > wishes. Technology has allowed ways to bypass or steal extra service. > This law now protects the ISP. There will be some ISPs that continue to > allow and support NAT. The problem is that these laws not only outlaw the use of NAT devices where prohibited, but also the sale and possession of such devices. Futher, I think many would disagree that the use of NAT where prohibited necessarily should be considered an illegal activity. Note that the customer is still paying for a service, so the question of "theft" is debatable. It is one thing for an ISP to terminate service for breach of contract by using a NAT device, it is quite something else to put someone in prison for such a breach. I found one large broadband provider in Michigan that prohibits the use of NAT devices -- Charter Communications. Comcast, Verizon, and SBC seem to allow them for personal household use (although they do have value-add services that charge extra for multiple routable static IP addresses). > > Correct me if I'm wrong, but the DCMA(sp?) already performed this > function. Circumventing copyright protection has always been deamed > illegal and they are just now implementing laws to help protect it from > technology. The DMCA refers specifically to copyrighted works and has several (somewhat weak) safeguards built-in (must be primarily designed to circumvent, of limited commercial use, allowances for reverse engineering for interoperability purposes) These state laws cover both ISP services and copyrighted content services and have almost nothing in the way of safeguards. > > > Heck, it is possible to real this Act to prohibit changing your > > operating system from M$ to Linux. > > > It would be a far stretch, and I do not feel that it would hold up in > court as applying. > > One thing to note, a telecommunications service provider is defined in > such a way that anyone running a network is included. The Michigan law covers only commercial telecommunications service providers that charge fees. It most definitely does not cover anyone running a network.
Re: 69/8...this sucks
Appologies for the poor attempt at humor... However, there is some useful content at the end of the message. Essentially, I think this is one of those problems that can never fully be solved. Just as we will never get every last worm-infected host off the network. The best that we can do is provide procedures for those who filter on unallocated space so than can keep their filters updated on a timely and accurate basis. For those who do not wish to use such procedures, we should stridently urge them to filter only on martians, not unallocated space. -Larry Blunk Merit > I agree. > > -Original Message- > From: Rick Duff [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 2:09 PM > To: 'Larry J. Blunk'; 'Andy Dills' > Cc: 'Ejay Hire'; [EMAIL PROTECTED] > Subject: RE: 69/8...this sucks > > > > I've never posted to the list, just lurk, for over a year now, but this > has to be said. Can we please take this discussion off-list to private > conversation. It's gotten worse then spam. I see a nanog message and > just start deleting them now. > > -rd > > > -----Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Larry J. Blunk > Sent: Tuesday, March 11, 2003 1:01 PM > To: Andy Dills > Cc: Ejay Hire; [EMAIL PROTECTED] > Subject: Re: 69/8...this sucks > > > > > > > On Tue, 11 Mar 2003, Ejay Hire wrote: > > > > > Er, guys... How does this fix the problem of a Malicious user > > > advertising a more specific bogon route? > > > > Come on...clearly you haven't been paying attention. > > > > You need LDAP filters. LDAP filters and a South Vietnamese revolution > > against the IRRs for being fragmented and greedy. > > Careful. We are watching and are prepared to ruthlessly squash > any attempted rebellion. > > > > > And if that doesn't poison your inverse arp, then multiplex a private > > bogon server with a centralized host scanner-based DNSBL. Don't forget > the > > trailing dot! And don't forget to invert the subnet mask! > > > >Hey, I've already thought of all that and captured it in an > XML schema (with ASN.1 encoding)! I will be presenting an Internet > Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. > > >Seriously... As has been suggested, I think we need to do > a better job of identifying the population and type of devices > that are filtering these prefixes. Are they really predominately > BGP speaking routers, or largely some mishmash of non-BGP speaking > firewalls/proxies/NAT's? > >If it's the former, then a BGP based solution has some merit. > If the latter, I think it unreasonable to expect these > firewalls to speak BGP. What's needed is a canonical > represention of the bogon list and some tools to generate > the filter list in the appropriate config format for a number > target devices. > >There's already a canonical list maintained by Rob Thomas > in the RADB (see fltr-martian, fltr-unallocated, and > fltr-bogons). I've suggested to Rob that he may want > to include a PGP signature in a remarks section of the object > to provide a greater level of confidence (hopefully with > a key that's escrowed somehow -- god forbid anything should > happen to Rob). I should also note that some of the > RIR's have indicated they will be providing more > precise information on their unallocated space. > >As far as tools go, while IRRToolSet has extensive > support for RPSL, it may be too complex for a novice > Net admin. Perhaps some simple Perl scripts to generate > filter configs from RPSL filter objects would be useful? > > > Larry Blunk > Merit >
Re: 69/8...this sucks
> > On Tue, 11 Mar 2003, Ejay Hire wrote: > > > Er, guys... How does this fix the problem of a Malicious user > > advertising a more specific bogon route? > > Come on...clearly you haven't been paying attention. > > You need LDAP filters. LDAP filters and a South Vietnamese revolution > against the IRRs for being fragmented and greedy. Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion. > > And if that doesn't poison your inverse arp, then multiplex a private > bogon server with a centralized host scanner-based DNSBL. Don't forget the > trailing dot! And don't forget to invert the subnet mask! > Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
RADB news and NANOG helpdesk hours
This is an update on recent changes to the Merit RADB
Internet routing registry and announcement of helpdesk
hours at the Phoenix NANOG meeting.
In December of 2002, the RADB was officially rechristened
the "Merit Routing Assets Database" and a redesigned website
at www.radb.net was unveiled. In addition, there is now a
web-based interface for RADB additions and updates. This
interface may be reached at the following URL --
http://www.radb.net/cgi-bin/radb/irr-web.cgi.
Merit has been actively involved with the RPSLng effort
to update the RPSL standard to support IPv6 and Multicast
routing policy. We have an initial implementation of the
specification as documented in the following Internet draft:
http://www.ietf.org/internet-drafts/draft-damas-rpslng-00.txt
We expect to deploy this implementation in RADB registry shortly.
In addition, we are working with Internet2 members to
develop the I2 routing registry as an IPv6 routing registry
and resource for the Internet2 community.
The RADB team will once again hold a helpdesk at the NANOG
meeting. Helpdesk hours are as follows:
monday 10:15 break
monday 3:00 break
tuesday 10:35 break
tuesday 12:00 lunch
Regards,
Larry J. Blunk
Merit RADB
Re: The Cidr Report
> > Previously, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > > AS690521 326 19537.4% MERIT-AS-27 Merit Network Inc >. > > Come on, Susan, have your folks get with the program. :-) > > -- > Douglas A. Dever [EMAIL PROTECTED] > 216.373.8517 - DID > 216.401.5888 - Cell AS690 was originally aquired by Merit for the NSFNET T3 network and subsequently assumed by ANS --> AOL --> UUNET --> WorldCom (I'm not entirely sure if this ordering is correct). I've nagged Lee Howard a couple times to get this transferred over. Perhaps I need to go through a less busy person. -Larry Blunk Merit
RADB Unpaid Maintainer Clean-Up status and other news
This past April, Merit announced it's intention to begin removing RADB registry objects due to non-payment of the annual maintainer fee. At this point, the unpaid maintainer clean-up process is considered complete. When the clean-up was announced, there were approximately 3150 maintainers registered in the RADB. With the completion of the clean-up, there are now 1972 active maintainers. The RADB team would now like to move forward with improving the database accuracy. We will be deploying notification and update tools to better assist maintainers in making sure their objects reflect configured routing policy. In other news, Merit RADB staff will again be hosting a helpdesk at next week's NANOG meeting. Staff will be available during breaks on Monday and Tuesday to accept questions/comments regarding the RADB and routing registry issues. Finally, Merit is pleased to announce the 2.1.5 release of the IRRd routing registry daemon software. The release is available at www.irrd.net. For Merit RADB, Larry Blunk
Internet Routing Registry Help Desk at NANOG 25
Merit RADB technical staff will be hosting an Internet Routing Registry (IRR) Help Desk at NANOG 25. The desk will be staffed on Sunday 7:00 - 9:30PM, and from 1:00 - 1:30PM and during breaks on Monday and Tuesday. A list of potential discussion topics are included below -- -- General IRR topics * RPSL concepts and usage * Benefits of using the IRR * Using PGP and CRYPT-PW authentication * Using the IRR to configure routers -- RADB/IRRd specific topics * Registering for RADB service * Updating/Removing your RADB objects for consistency * Determining the status of your RADB registration and objects * RADB billing questions and issues * Status of the RADB clean-up * Feedback on the RADB service * Demo of upcoming RADB web interface for updates * IRRd software questions and feedback In addition, RIPE NCC technical staff will be available Sunday from 7:00 - 9:30 PM to accept feedback and questions on the IRRToolSet. For further information or questions, please contact [EMAIL PROTECTED] -Larry J. Blunk Merit
RADB renewal deadline April 2
This is a reminder that effective April 2, 2002, Merit will begin the process of removing RADB maintainer objects that have not been renewed and paid for 2002. The clean-up project will take several weeks to complete. The estimated completion date for removal of all unpaid maintainers is May 31. Maintainers scheduled for removal are listed at http://www.radb.net/docs/deletelist.html. You may also query our payment database at the same URL to determine the status of your maintainer. About 1,000 maintainers with valid route objects that are currently being announced to the Internet are scheduled to be removed. These maintainers will be removed gradually -- but steadily -- over the next several weeks. It is not too late to contact Merit to make arrangements to continue your RADB service. If you wish to renew service, please send e-mail to [EMAIL PROTECTED] or or go to our online payment page: https://www.merit.edu/cgi-bin/radb/pay/alive All deleted RADB data will be archived by Merit. We will be able to restore deleted maintainers even if payment is made after April 2. If your data is removed as part of the clean-up project and you wish to renew service, please contact [EMAIL PROTECTED] URLs: To renew service and pay online: https://www.merit.edu/cgi-bin/radb/pay/alive To view or query the list of maintainer IDs scheduled for removal: http://www.radb.net/docs/deletelist.html To review the RADB maintainer object agreement: http://www.radb.net/docs/agreement.html For general information: http://www.radb.net -- Larry J. Blunk Merit Network, Inc. Ann Arbor, Michigan
