February 2006 - Test - lists.nanog.org

Drone Army (how to contact)?
by infowolfe 17 Feb '06

17 Feb '06

I'd really like to know how I can get ahold of the people that do the Drone Army reports, as I am a serveradmin on an irc network that was identified as being abusive. If you're responding as part of the Drone Army, please reply to me off list. Allen Parker

1 0

ignore the word "radical"
by Edward B. DREGER 16 Feb '06

16 Feb '06

Let's look at this a little more carefully. Pretend for a moment that you operate a network "U". Pretend that someone else operates a network "E". Pretend that you share a downstream customer "C". So far, so good. "C" has several different locations, none of which are directly interconnected. They advertise their aggregate netblock, which makes its way to the global table. They also advertise longer prefixes for you to deliver traffic to the specific location; these are tagged NO_REDISTRIBUTE. This does not increase the size of the global table. This does not require proactive registration of an ASN for every potential customer, nor for every other transit provider in the world. It does not require a different ASN for each location "C" has. It does not effect any other number of wacky things that have been suggested. It does require peering between "U" and "E", or de-aggregated prefixes to be leaked between the two. (Ask your transit provider; you're paying them for this service, so it makes them money.) Now say that one person from each location sends in a monthly check for "their" portion of the service. Panic! Horror! Routing no longer works the same way! Yes, aggregation means less flexibility. One therefore aggregates likes together. (Thanks David for the addressing/topology quote.) Some of you might even do this with your global announcements. Must "C" renumber when changing providers? Yes. Sounds familiar. I'm pointing out a way to give consumers dual-homing _today_, using installed technology.[*] I'm not claiming that it answers the question of portable /32s. I'm not saying that they'll be able to prepend AS_PATHs arbitrarily, send BGP communities, etc. -- and I'd even go so far as to claim they typically don't want to. [*] Excepting CPE equipment, which would need a simple BGP speaker. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

2 2

Verio
by trainier＠kalsec.com 16 Feb '06

16 Feb '06

I need a Verio Web Hosting (SME) contact to please contact me off-list. Thanks, Tim Rainier

1 0

keeping the routing table in check: step 1
by Edward B. DREGER 16 Feb '06

16 Feb '06

Hopefully this thread will be quick and less convoluted. Rather than simply alluding to "one prefix per ASN", I'd like to detail an allocation scheme that works toward that. Find the largest contiguous block. Split in half. Round to appropriate boundary. Assign. Space at the end of the block is reserved for expansion. Ignoring special subnets for simplicity: 0/x, 128/x, 64/x, 192/x, 32/x, 96/x, 160/x, 224/x, 16/x, 48/x, 80/x, 112/x, 144/x, 176/x, 208/x assuming all grow at equal rates. 96/x ends up growing quickly? No problem. Skip 112/x for the time being. In short, allocate IP space logarithmically. Start with /1 alignment, proceed to /2, then /3, and so on. Keep the array as sparse as possible so an assignment can be extended without hitting, say, a stride 4 boundary. Perhaps RIRs should look at filesystems for some hints. Imagine a filesystem that's 30% full yet has as much fragmentation as IPv4 space. Something is wrong. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

4 4

(OT) VERIZON NOC CONTACT PLEASE!!!
by Rich Sena 16 Feb '06

16 Feb '06

All other flame away... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

2 2

a not so radical proposal for PI in ip6 world: Hierarchial routing tables
by Joe Maimon 16 Feb '06

16 Feb '06

Since the list seems to be accepting topics relating to ipv6 and PI multihoming AGAIN, I thought I would chime in again with my pet idea. Hierarchical routing. It worked for name resolution. It would work for todays routing table, which is the routing equivalent to the host file of old. Let there be a single large prefix that will be used for all PI assignments. Let the single large prefix be further divided into "geographic regions" (nod to Michael D.) Let policies for assignment from this prefix take geographic location into account, and be SMALL, so that another prefix will never be neccessary. Filtering policies include the recommendation to filter out all prefixes longer than either the single large one and/or the local geographic ones. All ISP's hosting customers with prefixes inside the PI prefix would need to advertise at a minimum both the global PI prefix and the appropriate geographic PI prefix. Fast Forward 5 years. Now there are 8 million PI prefixes advertised. Most ISP's routers cannot hold them and all the other 2 million non PI prefixes. Instead ALL ISP's operate a 2 tiered hierarchy of routers. Those that have non-PI prefixes and those that do. The routers with only non-PI prefixes may hold the ISP's local PI prefixes but will filter out any others learned. The routers with only PI prefixes peer using multi-hop BGP to other providers routers who have PI prefixes. The ISP must announc the global and applicable geographic PI prefixes so that PI destined traffic is attracted to their AS. The ISP tries to keep a full table of PI prefixes so that they can MPLS TE/L2Tpv3/source route/ incoming traffic attracted by their non PI routers to their peer's handoff. This is the key. Using a mechanism OTHER than a full table on all routers who handle the packet transiting through the AS. If a full table is impossible, the ISP may choose to operate an array of the routers, each ibgp advertising one of the geo PI prefixes and holding only a full table for that prefix. Other filtering schemes are possible. Some ISP's may opt to host NO PI customers. Then they do not need such an expensive router and they do not need to announce any PI prefixes. Some ISP's may opt to NOT announce the PI prefixes. They will have to rely on their PI-Peers to attract the desired traffic and route it to their AS. Some ISP's may opt to purchase routers capable of a 12 million prefix RIB and they will not operate such a hierarchy at all, except that their peers will undoubtedtly include ISP's who do and will need mutli-hop bgp, and those that dont and will filter all those PI prefixes out. Perhaps one day multicast prefixes will need the same kind of hierarchy. Or some other class of prefixes. But obviously a global table is going to need severe limits in expansion. As for the problems of attracting unwanted traffic and handing packets back and forth between an AS's forwarding plane routers and routing plane routers, I am betting that if the problem of large table growth is so severe, the economics would favor using twice/thrice the bandwidth and fewer expensive routers than saving bandwidth and purchasing many large expensive routers. In other words, this is a solution that can be tested and driven by the marketplace. It needs no new technology standards. All that is neccessary is some policies for PI assignment. Customers who want it will spur its adoption. ISP's wishing to host those customers will spur its implementation. ISP's filtering their table to reduce size will ensure thatg hierarchy is needed. Last time proposed, I had about two directly related comments. Feel free to ignore me again this time. Joe

1 0

a truly radical proposal
by Edward B. DREGER 16 Feb '06

16 Feb '06

Consider: RIRs refuse to grant ASNs to dual-homed leaves. Transit providers _must_ cooperate with each other. Hopefully they coalesce joint ASNs and space responsibly before sending such merrily along to the global table. Voici, non-portable ASNs and "minimum height to ride" requirements for a portable, personal ASN. This really isn't much more restrictive than today's policies, and changing an ASN is easy for small leaves. The biggest pitfall I see: Imagine having to renumber when _any_ upstream changes. I propose that this is reasonable for > /24, where such is the status quo. For <= /24 non-PI space, one could use non-coop space from a specific upstream -- again, the status quo. On a related note: Someone pointed out off-list that the "coop ASN" approach requires creating a new ASN when one changes providers. Yes, but this still uses no more ASNs (unused ones are returned, right?) than if each leaf registered its own portable ASN. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

2 1

reg-ops now becoming fully operational
by Gadi Evron 16 Feb '06

16 Feb '06

As originally sent to the registrars list by Rick Wesson... Through 2005, the reg-ops (Registrar Operations) mailing list which was established after the first Panix incident, was working by trial and error, learning from past mistakes, formalizing reporting guidelines and operating procedures. The mailing list now holds representatives from most of the big registrars. reg-ops also holds liaisons to NSP-SEC, DA/MWP, ICANN, SSAC, NANOG and the root servers. Other than the registrars, there are also a limited number of vetted individual from the anti-spam, anti-phishing and security industry. The purpose of the list is to relay reliable information in real-time from the industry to registrars on issues such as scams, phishing, etc. Real-time issues are handled with care while other reports can be made digested, periodically. The list is mostly operational and therefore there is not much chatter. However, security and operational issues which concern registrars or cooperation/information sharing happens when it is needed. The list is not open to the public, and subscription requires vetting. Please contact me or Gadi Evron <ge(a)linuxbox.org> directly to be added to the group. Thanks, Gadi.

4 4

IRS goes IPv6!
by Jeroen Massar 15 Feb '06

15 Feb '06

I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) Greets, Jeroen -- OrgName: Internal Revenue Service OrgID: IRS Address: 1111 Constitution Ave. NW City: Washington StateProv: DC PostalCode: 20224 Country: US NetRange: 2610:0030:0000:0000:0000:0000:0000:0000 - 2610:0030:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2610:0030:0000:0000:0000:0000:0000:0000/32 NetName: IRSNET6 NetHandle: NET6-2610-30-1 Parent: NET6-2610-1 NetType: Direct Allocation NameServer: NS1.TREAS.GOV NameServer: NS2.TREAS.GOV NameServer: NS21.TREAS.GOV NameServer: NS1.CIS.FED.GOV Comment: RegDate: 2006-02-13 Updated: 2006-02-13

14 17

Re: IRS goes IPv6!
by Andrew Dul 15 Feb '06

15 Feb '06

> -------Original Message------- > From: Christopher L. Morrow <christopher.morrow(a)verizonbusiness.com> > Subject: Re: IRS goes IPv6! > Sent: 14 Feb '06 08:31 > > On Tue, 14 Feb 2006, Jeroen Massar wrote: > > > I Ar Es, > > > > At least they have received the 2610:30::/32 allocation from ARIN. > > Lets see if they how taxing they find IPv6 ;) > > so.. this is surprising why? the us-gov mandate for ipv6 uptake will mean > lots of us-gov folks will be spinning up justifications that they are a > 'service provider' and need a /32... cause they won't accept PA space (or > I don't think they will accept PA space as a long term solution) ... So isn't this yet another reason why we need a rational PI policy, so organizations don't have make up reasons why they are LIRs.

2 1