Re: People being removed from the list and such

pfui! unless someone has gone so far off the deep end as to be seriously impeding any other discussion on the list (google for "plonk":-), people should not be censored, period. we all can filter mail as we wish, just as we can bgp announcements. i submit that this discussion itself should be s

Re: BCP38 making it work, solving problems

> For example, how many ISPs use TCP MD5 to limit the possibility of a > BGP/TCP connection getting hijacked or disrupted by a ddos attack? i hope none use it for the latter, as it will not help. more and more use it for the former. why? becuase they perceived the need to solve an immediate p

Re: BCP38 making it work, solving problems

> Hmm, so let me figure this one out... Are you arguing against > BCP38 implementation/filtering, or what? no one is arguing against it. they're just trying to tell the religious zealots (who seem not to run large networks) why it is not deploying as rapidly as they might like. randy

in memoriam

abha ahuja died on this day in 2001 randy

Re: Big List of network owners?

> I have been looking around, but haven't found it yet.. Is there a text list > of who owns what netblock worldwide? ISP/Location/Contact. I am not looking > for anything searchable, but rather, a large, up to date list that I can > import to a database.. in general, we try not to make life th

Re: Big List of network owners?

tom, i happen to have kept the "internet manager's phonebook," the August 1990 bbn/nnsc publication of the whois data. you're welcome to ocr it and see how many of the contact data are still valid. on a spot check: for my own entry only the email address still is still correct, sob's phone and

Re: Big List of network owners?

>> i wish i could remember which beatles' (i think it was) song >> had the refrain "we have all been here before." > close, but California, harmony well, at least we learn who has a better memory than i :-) the winners are, in order of appearance in my mailbox, Joe Abley, Charles Cala, and, of c

Re: what's a good way to annoy the hell out of somebody at chello.be?

we all have this kind of problem. if you're on freebsd, man ipfw. i am sure there are similar on other oss. randy

Re: Important IPv6 Policy Issue -- Your Input Requested

> I must admint, I'm really not up on the more subtle aspects of v6 > addressing nor have I read the drafts you posted, but I've never > understood why we needed a new set of RFC1918-like IPv6 space. because there is not enough v6 address space? because we like nats? because we think we can't get

Re: Important IPv6 Policy Issue -- Your Input Requested

>>> I must admint, I'm really not up on the more subtle aspects of v6 >>> addressing nor have I read the drafts you posted, but I've never >>> understood why we needed a new set of RFC1918-like IPv6 space. >> >> because there is not enough v6 address space? >> because we like nats? > > There's n

Re: Important IPv6 Policy Issue -- Your Input Requested

> is very unwise. One of the problems with site local was the prefix got > allocated but the work on what it would mean never got full community > support. Doing the same thing twice just strikes me as dumb. do you mean 1918 twice or site-loco twice? both are stoopid. either is stoopid. it'll

RE: Important IPv6 Policy Issue -- Your Input Requested

> 2) There is a cost associated with assigning globally-unique space no > matter how you do it. This cost could be too high for some application -- > RFC-1918-style space is free. you want unique space but not pay for the administration of it. absolutely brilliant. > 3) There is a c

Re: Important IPv6 Policy Issue -- Your Input Requested

> To the end user of address space it is absolutely irrelevant how large > the total space is or what the size of the routing table is. What > matters is how much cost/effort you need to expend to get your address > space, and what you need to use it for. A guarantee of global > uniqueness has a

RE: Important IPv6 Policy Issue -- Your Input Requested

> I'm not sure why the proposal wouldn't block off some space to > cover "unforseen" circumstances and leave it at that. uh, 7/8 of the ipv6 space is currently blocked off for unforseen circumstances. like a place to move after we have made as much of a bleedin' mess of fp=001 as we have of ipv

Re: Important IPv6 Policy Issue -- Your Input Requested

> In today's networks, printers do NOT need global addresses. let me make sure i understand this. in order not to have to pay for the address space for a my enterprise's printers, they are supposed to make separate ether runs to them parallel to all the workgroup runs, so they can route them fun

Re: Important IPv6 Policy Issue -- Your Input Requested

> I have devices that have no need, never will have a need, to ever > talk outside of the internal networks, nor do I want some > brain dead user to drop some stupid little device on the network > and tada, route access to some of my inside network simply because > the addresses are valid. I want

Re: Important IPv6 Policy Issue -- Your Input Requested

> "Get a firewall" is not a valid response when you have lusers > to drop the latest netgear whatever onto their PC and dial > to some provider somewhere. Your firewall is useless to > protect that segment. In many cases NAT is the ONLY > protection you end up with in this scenario, a scenario

Re: Important IPv6 Policy Issue -- Your Input Requested

> For the record, we use 1918 address range on several of our public routers > meaning you will get legitimate traffic from this address space, atleast > from us unless you are filtering it (which is of course all your decision). > Filtering any type of traffic at all by a transit provider with

Re: Important IPv6 Policy Issue -- Your Input Requested

> If IPv6 had "local scope" addresses, then NAT would not be > necessary to prevent traffic from flowing through the > unauthorized link. yes. just like we see no 1918 leakage now. randy

Re: Status of FCAPS model? Useful? Obsolete?

> We see a lot of interest among enterprises in ITIL for IT service > management, which I'm guessing would overlap the FCAPS framework. s/a lot of interest/we want to sell/

Re: Important IPv6 Policy Issue -- Your Input Requested

> I could be wrong, I am just a chemical engineer. If this was a > distillation column or a raction vessel I might be more sure : actually, i think you happen to be one of the maybe 25% of participants in this discussion that is an actual operator on a real network. rarer and rarer. :-( and if

Re: Important IPv6 Policy Issue -- Your Input Requested

> I see this a lot recently: You are mixing up RfC1918 and NAT. > > If I have globally unique addresses I can NAT them as well > as 10/8. One has nothing to do with the other. > > Having to NAT RfC1918 addresses to reach the internet, does not imply > that I have to have RfC1918 to be able to d

Re: Important IPv6 Policy Issue -- Your Input Requested

> What are my options today to obtain ip address space? My requirements are > well met by a /27 subnet. ARIN won't give me a globally unique /27 for > personal use. in ipv6, you'll get a /32 or whatever is in fashion this week. that should do you just fine. randy

Re: How to Blocking VoIP ( H.323) ?

> What business issue/problem are you trying to address by > blocking VoIP? an incumbent telco which also has the monopoly on ip might want to prevent bypass. welcome to singapore, and remember to try the chili crab. randy

anycast roots

which roots are anycast? c f i j k? randy

Re: anycast roots

>> which roots are anycast? c f i j k? > b m thanks. which are widely anycast, i.e. at more than three or four locations OR on three or more continents? randy

Re: anycast roots

> and the good folks on nanog would know this why? dunno, bill. maybe because it has to do with network operations? but we did get the answers we needed, thanks to some of those good folk. and non-answers from others. all as expected. welcome to the internet. randy

Re: anycast roots

> Don't presume to speak for the other operators please. got a mirror around the house?

RE: I want my own IPs

> Good to know. I always though it was a /21 or /20. I'm pretty sure > ARIN rules change with the weather, though. no. it's the downdraft from the black helicopters randy

Re: Any Sprint BGP people out there

> We have a customer that has Internet access through SBC. They lost their > connection yesterday morning and are about ready to go out of business. > We got additional fiber to their location and are now trying to announce > their prefixes to Sprint. Of course they don't belong to us and wonde

Re: The Cidr Report

> ASnumNetsNow NetsAggr NetGain % Gain Description > > AS18566 7516 74599.2% CVAD Covad Communications > AS4134 825 178 64778.4% CHINANET-BACKBONE >No.31,Jin-rong Street > AS4323 794

Re: The Cidr Report

>>> ASnumNetsNow NetsAggr NetGain % Gain Description >>> >>> AS18566 7516 74599.2% CVAD Covad Communications >>> AS4134 825 178 64778.4% CHINANET-BACKBONE >>>No.31,Jin-rong Street >>> AS4323

RE: The Cidr Report

geoff, your proggy already knows what filter list(s) would keep us from carrying the polluters' rubbish. any chance you could generate the filter code for juniper, procket, and cisco so automated router builds could fetch it with batch wget or ncftp or whatever? another cutie would be if whovev

Re: The Cidr Report

> eh, since I singled out covad: (and I feel bad for it now) > what about for COX? what about for UU (doh, thats me...or our tac or > something, I'll look/ask) thanks! randy

Re: anycast roots

> i'm saying that there is no place that is public that > has connectivity information for all instances of the > "B" servers. considering, do we care? i sure don't. randy

Re: Any Sprint BGP people out there

>> On Fri, 12 Nov 2004, Randy Bush wrote: >> sprintlink does not prefix filter, they only as-path filter > From personal experience with multiple Sprintlink customers' BGP, > that's not true for all Sprintlink customers. i should also have said that my knowledge w

Re: IPV6 renumbering painless?

> Total ASes present in the Internet Routing Table: 18421 < > 30% usage and we need 32 bit ASNs? george and geoff's movie gives an interesting perspective on number of asns allocated and number of asns announced. like address space, i suspect we have a general issue of if and how we recover

Re: IPV6 renumbering painless?

> I guess the IETF and router vendors prefer larger fields than > having LIRs do the work they are supposed to do. i don't think i would phrase it just that way. it may be that the rirs, and the ivtf are not optimistic that lirs will do it. and lirs, because of being nearer the folk holding the

Re: IPV6 renumbering painless?

> the IETF thus far has been adamant that only ISPs will get PI space the ivtf got out of the entire policy decision space a few years ago. you're welcome. randy

RE: The Cidr Report

> Interestingly enough what Covad appears to be saying is: > > If we had a way to announce two things > > 1 - here are the advertisements for covering aggregates for Covad > > AND > > 2 - do not believe any more specifics for these address blocks, as they are > NOT part of Covad's routing pol

Re: anycast roots

> root-servers.org is not definative. why do you think it is? because the community expects the root server ops to be helpful, open, honest, and transparent. you know, all that service to the community stuff. damned shame not all seem to be. randy

Re: who gets a /32 [Re: IPV6 renumbering painless?]

> in august 2002 there were no v6 isp's. you're kidding, right? let's not be too americocentric. i assure you there were. i think even c&w might have been deploying in the states then. randy

anycast stability experiment

the verisign gang gave a good presentation of "Life and Times of J-Root" at the recent nanog meeting' see . on foils 27 to 29, they reported non-trivial routing jitter and therefore suggested "DO NOT RUN anycast with stateful transport." on the

Re: Risk of Internet collapse grows

> last year we *measured* isp maps as part of a research project called > rocketfuel and found that the marketing maps can differ significantly from > the real ones quite a bit because of lack-of-detail, outdated-ness, or > optimistic-projections. a paper describing the methodology and the maps >

Re: Risk of Internet collapse grows

> I just don't see how an outside probe can determine the true topology of a > network. you may want to *read* the paper

Re: Networking in Africa...

> Would that friend be so kind as to name more than a handful places in > Africa with IP connectivity (multinational companies do not count). fyi, all countries in africa are ip connected. dunno how big your hands are, but there are over 50 countries in africa. randy

Re: Networking in Africa...

>>> Would that friend be so kind as to name more than a handful places in >>> Africa with IP connectivity (multinational companies do not count). >> fyi, all countries in africa are ip connected. dunno how big your >> hands are, but there are over 50 countries in africa. > Pardon me for not count

Re: Networking in Africa...

> Try finding some IP connectivity while in Nigeria. do tell us your personal experience and when it was. randy

RE: Operational Issues with 69.0.0.0/8...

> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP there already has been a canadian ip address registry. there no longer is. learn from history. randy

Re: Route Views

> Some prefixes in the Route Views routing table do not have a prefix > length specified. For example, because they are their 'natural' length, i.e. old style A/B/C

Re: Operational Issues with 69.0.0.0/8...

> This gets to the heart of the matter. It is now 8 years later and RADB is > not catching on. But during the same time period some other UMich people > worked on a more general purpose directory service called LDAP and that > one is catching on. LDAP technology can be made to do the job that w

Re: DDos syn attack

> This is also a very viable solution, provided the customer has > provisioned for this with lower ttls on their DNS records, which > ALOT of people (thankfully) don't do actually, a bunch of research now shows that low ttls on A RRs (that are not the A RRs of NS RRs) has little effect. in the c

Re: US-Asia Peering

> Where the same pseudo wire provider connects to say LINX, AMSIX, > DECIX your only a little way off having an interconnection of > multiple IXs, its possible this will occur by accident .. and l2 networks scale s well, and are so well known for being reliable. is no one worried about storm

Re: US-Asia Peering

> Well, first I think we need to agree that there are two different cases here: > 1) interconnecting IXes operated by the same party, vs. > 2) interconnecting IXes operated by different parties. > > In the first case an IX operator can shoot himself in the foot, but there > is only one gun and

Re: Puerto Rico Peering Point, or existence thereof.

> However, NOTA doesn't have either AT&T or WorldCom... so, did any of the much-ballyhooed florida (misnomered) naps actually manage to attract the significant (== big tier-1) isps? randy

RE: Puerto Rico Peering Point, or existence thereof.

>> so, did any of the much-ballyhooed florida (misnomered) naps actually >> manage to attract the significant (== big tier-1) isps? > http://www.napoftheamericas.net/membersrepresentativecustomerlist.cfm > http://www.napoftheamericas.net/memberscarriers.cfm are they connected and peering, i.e. pa

Re: Less than 2% of computer attacks on military are successful

> After last weeks spam run on Iraq, the US military and NIPC are > concerned Iraq might be behind a rise in electronic attacks > against government and military networks. and we are supposed to have sympathy for those who struck the first blow? rofl! randy

Re: double postings

> anyone else getting postings (at least) twice? someone else told > me they were seeing the same thing. Anyone from Merit at the > wheel? if we're talking repetitive content, the multiplication factor seems to be a couple decimal orders of magnitude higher than a mere doubling

Re: Level3 routing issues?

> Wow, for a minute I thought I was looking at one of our old > plots, except for the fact that the x-axis says January 2003 > and not September 2001 :) :) seeing that the etiology and effects of the two events were quite different, perhaps eyeglasses which make them look the same are not as usef

Re: mSQL Attack/Peering/OBGP/Optical exchange

> We don't know anything we could do with 50ms provisioning without > making a disaster (c) smd 2001. indeed. but i sure would like one or two day provisioning, as opposed to 18 months. randy

Re: EuroNOG

instead of spending our time and energy putting down fools, let us try to be constructive. let's put our money where our mouths are. i am soliciting presentations for the eof meeting in barcelona. of particular interest a presentations on operationally oriented research, heretofor little-present

Re: Streaming dead

huh? i thought it was in eugene where we were streaming the dead randy

Re: AT&T seems to have lost Houston

will anyone miss it? :-)

Re: M$SQL cleanup incentives

> I'd be very interested in hearing how opeators feel about 'pushback'. the only interesting thing i have seen in this space randy

Re: 223.255.255.0/24

> The outcome of the discussions at the Address Policy SIG will be posted > to this list. where, one hopes, discussion will continue, yes? randy

untied

could someone else please check the dns for www.united.com? the servers for united.com seem to delegate www.united.com, but the delegatee seems not to return an soa. i get very confusing results. randy, feeling stoopid

Re: untied

> btw, when querying bind9 and requesting > 'any www.united.com', i get servfail, but when requesting > 'A www.united.com', i do get a response. that is the reaction to their misconfiguration. i am in a dual-stack universe over here (iij/tokyo). so the browser, looking for an A or , probab

Re: untied

btw, for every answer from someone with clue also trying to debug united's little mess, i get six emails from idiots, a lawyer, wannabes, and other clue-free lurkers, whose inability to diagnose dns is amusing at best, telling me how it works for them. if you don't actually know the dns seriously

Re: untied

ross? lazarus arises! wow! >> could someone else please check the dns for www.united.com? > Doesn't look good... they seem to be making similar messes with ual.com, ua2go, ... and all the stuff that links from their pages. but it probably 'works' if your host is not dual stack, could you plea

Re: anti-spam vs network abuse

> Scanning is always a precursor to an attack this is clearly not true, as scans are done for research and other goals. and conversely, all attacks are not preceded by scanning. randy

Re: BGP to doom us all

> What a crock of crap. Knowing who someone is doesn't stop them > from causing intentional or unintentional problems. In fact, > authentication is more likely to cause people to become > complacent wrt their filtering policies. Hey I've authenticated > that router so it's going to only send me

Re: BGP to doom us all

> http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed actually, the article is not all that far off reality as i see it. the exception being that the ietf has NOT been diligently pursuing sBGP but rather a lot of the effort is going into a 3/4 hack being pushed by vendor laziness. randy

Re: BGP to doom us all

> I think the only problem with the comments is that they > over-estimate the benefit of that level of security relative > to the overhead it requires. crypto hardware has become cheap. randy

Re: BGP to doom us all

> Cheap to buy, but the time for processing each certificate will > increase with the size of the routing table, and we just end up > replicating the problem of recalculating large routing tables, > but now with certification, no? no. you *really* may want to read up on sbgp before attempting

Re: Building Cited for Housing Fuel Tanks Catches Fire [NYT]

> An electrical fire broke out in the basement of an office tower > in TriBeCa yesterday, four months after building inspectors said > they had discovered illegal diesel fuel tanks installed on the > upper floors of the tower. basement. roof. what is it i am not getting here? osama bin elevato

Re: 69/8...this sucks

> Look, there's no quick fix solution here. so let's see how much of a kludge we can make to show how clever we are. randy

Re: Route Supression Problem

you might want to look at . then again, you may not. it's depressing. randy

Re: Route Supression Problem

> You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. randy

Re: 69/8...this sucks

> The problem is small mom&pop ISPs and companies where the NOC and the > senior secretary share a desk, and possibly a name. maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?

gender and nanog

> It is offensive to many people (both male and female) when someone > automatically assumes that an "unknown" person is male. though not offended, it does tell me a lot about the person making the assumption. and it ain't positive. but that nanog is yet another male dominated technical culture

Re: route filtering in large networks

> How would the banana eaters screw up applying the same prefix-list > outbound to all neighbors? by spending [some small part of] their time configuring routers as opposed to building tools to configure routers demonstratably correctly. when fingers 'touch' routers, bad things are bound to happ

Re: route filtering in large networks

> If you are not ready willing and able to keep your lists updated, you > probably shouldn't have applied them in the first place. a poor but wise person who had the onerous task of managing me in the late '60s said i had a talent for stating the obvious. it was meant as a compliment. randy

Re: route filtering in large networks

> Verio has a history of being a prefix length nazi, but were they > that way about route validity? i can only speak in the quite past tense. but yes. due to limitations of routers (ever try a really long acl on a cisco?) and some large peers not registering, verio could not filter large peers

Re: BGP to doom us all

From: Stephen Kent <[EMAIL PROTECTED]> Subject: Re: BGP to doom us all Date: Wed, 2 Apr 2003 18:15:05 -0500 Folks, I was not subscribed to the workshop list when Randy forwarded this message at the beginning of last month. However, I would like to respond to the issues raised in the text. Stev

Re: An A record is an MX record and is a missing MX....

> MX records are only required if you want to have more than one mail > exchange servers to serve your domain, e.g. if you want to have a > secondary mail server as a relay if the primary server goes down. actually, i suspect the more common use is that one has a collector server for a lot of loc

RE: IANA reserved Address Space

> But not to be a pest but what are the odds > the IANA would ever allocate the 1 and 100 > nets to someone? 99%

Re: .mil domain

> In recent times, a lot of .mil have thrown up a whole bunch of null routes > to large sections of international address space. Good luck getting them > removed as this means they have a different definition of the internet than the one to which i, and i suspect others, are used, why should i

Re: rr style scanning of non-customers

> According to a study by America Online, 89% of the computers with > broadband connections are not safely configured. 91% of the computers had > what AOL categorized as spyware installed. In reality, the connection > method isn't the determining factor. > > http://www.staysafeonline.info/press

Re: rr style scanning of non-customers

>> so where is the authoritative web site >> > Plenty of *ix idiots running vulnerable systems and "servers", > too. Follow a Cobalt mailing list and live in fear. for which there are system-specific sites telling you how to lock it down, e.

Re: rr style scanning of non-customers

> http://www.nsa.gov/snac/winxp/guides/wxp-1.pdf > http://www.giac.org/practical/GSEC/Trevor_Cuthbert_GSEC.pdf > http://www.microsoft.com/windowsxp/pro/using/itpro/default.asp#section6 cool. thanks. in a side conversation, a friend from redmond says > http://www.microsoft.com/security/ > Has l

Re: IRR/RADB and BGP

> Our new ISP is asking that I create a maintainer object in the > RADB and associated AS/Routes for us to be about to eBGP peer. congrats. you got a quality provider who cares about good safe routing practice. > Is this just so they can dynamically build their prefix/as-path > lists? i would

it's 1918 in bologna

laptop plugged into an internet shop's ether in bologna. i decided to trace to an address i had roam.psg.com:/etc# traceroute 139.7.30.125 traceroute to 139.7.30.125 (139.7.30.125), 64 hops max, 44 byte packets 1 192.168.10.1 (192.168.10.1) 0.256 ms 0.199 ms 0.137 ms 2 192.168.20.1 (192.168

Re: it's 1918 in bologna

>> note the 37. address. cute, eh? and i thought omphaloskepsis >> was greek! > Someone is going to have fun when tat part of 37/8 gets assigned and used. as the us military is blocking overseas access to more and more address space, i guess non-american isps can use that space with impunit

RE: rfc1918 ignorant (fwd)

> ARIN required cable operators to use RFC 1918 space for the management > agents of the bridge cable modems that have been rolled out to the > millions of residential cable modem customers. this would be really amazing, as it would have required a time machine. the cable build was before arin ex

Re: WANTED: ISPs with DDoS defense solutions

>> Filtering the bogons does help, and everyone should perform anti-spoofing >> in the appropriate places. It isn't, however, a silver bullet. > it's necessary but not sufficient. anti-spoofing is useful, but vastly insufficient, and hence not necessary randy

Re: WANTED: ISPs with DDoS defense solutions

Filtering the bogons does help, and everyone should perform anti-spoofing in the appropriate places. It isn't, however, a silver bullet. >>> it's necessary but not sufficient. >> anti-spoofing is useful, but vastly insufficient, and hence not necessary > anti-spoofing eliminates certain

Re: Complaint of the week: Ebay abuse mail (slightly OT)

>> And so we should do nothing? > No, but neither should we plan on engineering a solution. not necessarily. as i have been trying to point out for some years, look at bellovin's presentation at a nanog a few years ago on "pushback" (sorry, i am on dialup and searches are a major pain). that is

Re: RPC errors

must be fun out there on the net today. one minute of counter accumulation deny tcp any any eq 135 (5721 matches) deny tcp any any eq 137 deny tcp any any eq 138 deny tcp any any eq 139 (17 matches) deny tcp any any eq 445 (1137 matches) randy

Re: Complaint of the week: Ebay abuse mail (slightly OT)

> not necessarily. as i have been trying to point out for some years, > look at bellovin's presentation at a nanog a few years ago on "pushback" > (sorry, i am on dialup and searches are a major pain). that isps have > not been beating up the vendors to work on this boggles the mind. taking an

Re: WANTED: ISPs with DDoS defense solutions

>> There are requirements one can make of vendors. > These have been made, several times :) In fact there is an IETF working > group pushing these requirments now, Mr. Bush could provide the details > that have slipped my addled brain. it is not a wg. but there is a draft being actively worked,

<    2   3   4   5   6   7   8   9   10   11   >