Re: Backbone IP network Economics - peering and transit

> > Peering? Who needs peering if transit can be > > had for $20 per megabit per second? anyone whose applications are too important to risk dependency on OPNs (other people's networks). -- Paul Vixie

Re: TCP RST attack (the cause of all that MD5-o-rama)

> A huge round of applause for everyone not doing RPF and egress filtering > where it is trivial to do so. You make everyones job that little bit > harder. > > You know who you are. well, no, actually, they mostly don't (know). -- Paul Vixie

Re: New VOIP Peering/Interconnection Mailing List Announcement

;t accept e-mail from yahoo here, since they don't do any kind of permission/verification and i got tired of JHD. which is too bad since i'm very interested in the topic of this mailing list. if you need a place to host a mailing list, i could ask around at my day job. -- Paul Vixie

Re: New VOIP Peering/Interconnection Mailing List Announcement

> is Paul is volunteering to host this i guess so, yes, since i'd like to be able to participate in it. > (perhaps on peering.com)? peering.com belongs to the old day job. if we needed a mailing list created, i'd be asking the current day job if they can do it.

Re: Maps

i have no affiliation with them any more (other than as a happy customer), so i don't know anything about their phone setup. -- Paul Vixie

Re: Barracuda Networks Spam Firewall

ce in there. according to <http://www.dcc-servers.net/dcc/graphs/>, most people get most of the same spam, even if this doesn't appear in local measurements. (note that these graphs are subtle and complex and wonderful, and deserve several minutes of careful study before you try to draw any conclusions.) -- Paul Vixie

Re: handling ddos attacks

to involve law enforcement and get some bad guys arrested, if you possibly can. this changes your costs from 10 hours to 15 hours but it actually puts some chips on the table and makes the game worthwhile. -- Paul Vixie

Re: handling ddos attacks

> Ok, I 'll buy that right now; we have a DDoS Attack on our core nameservers > from 66.165.10.24. Where do we start, do I call the police in Bellingham or > Washington State Police. We have blocked their ips but, we know they will > come in another way. the best thing is if you call the FBI, or

Re: Open Source BGP Route Optimization?

a) probably a whole hour spent on such research would turn up even more. -- Paul Vixie

yo, savvis, cox, comcast, and armstrong! (Re: The Cidr Report)

haunting this mailing list looking for post-dotbomb work. many of them would accept work as short term consultants to help you folks get down under the 80% level. just ask! -- Paul Vixie

Re: Points on your Internet driver's license (was RE: Even you can be

he rest of us, and your customers, catch various diseases, as long as *you're* ok. feh. > Paul Vixie proposed that people should be required to use personal Co-Lo ^^(1) > so the co-lo provider has collateral to seize when the customer fa

Re: Points on your Internet driver's license (was RE: Even you can

a fine thing if you would take advantage of this position to cause a general increase in the reputation-level of your customers' IP addrs. whether you do that with deposits, truck rolls, filtering, cyberjails, weekly training seminars, and/or lawsuits against microsoft and apple, is your problem not ours, since you make the profit from these customers. how you remain profitable and competitive while managing these risks is also your problem, again since you make the profit from these customers. google for "chemical polluter business model" if you want more background. -- Paul Vixie

Re: Points on your Internet driver's license (was RE: Even you can

> So you claim even the ISPs you ran yourself have never attempted to do > any of these things? the last access-side isp i had anything to do with running used uucp and shell and was just getting going on c-slip when i pushed off. (i assure that any rmail or rnews spam was grounds for suspension

Re: Points on your Internet driver's license (was RE: Even you can

> > so you aren't going to google for "chemical polluter business model", huh? > > I hope you also google for Nonpoint Source Pollution. > > ISPs don't put the pollution in the water, ISPs are trying to clean up > the water polluted by others. ISPs are spending a lot of money cleaning > up prob

Re: Points on your Internet driver's license (was RE: Even you can

e pipes that put the pollution where it can harm others. They have > continuous control over the process and ultimately decide who does or > does not put things into those pipes and influence the policies. yea, verily. -- Paul Vixie

Re: "Default" Internet Service (was: Re: Points on your Internet

> >We have methods of dealing with these abuse problems today, unfortanately > >as Paul Vixie often points out there are business reasons why these > >problems persist. Often the 'business' reason isn't the tin-foil- > >hat-brigade's reason so much as &

Re: Points on your Internet driver's license (was RE: Even you can

only way to get this done, i'm willing to pay -- even though i own the routers on both ends of my home t1. -- Paul Vixie

yo, sean (Re: "Default" Internet Service (was: Re: Points on your Internet)

05-27 | 63.202.127.11 | 1 2002-12-11 | 2003-02-16 | 63.202.127.12 |76 2002-12-11 | 2004-04-27 | 63.202.127.13 | 202 2002-12-13 | 2004-04-28 | 63.202.127.14 |18 2003-09-04 | 2003-09-04 | 63.202.127.162 | 1 (595 rows) -- Paul Vixie

Re: "Default" Internet Service (was: Re: Points on your Internet

s, trust me!") for an annual fee of > > $(0.75*N). if the initial value of N were $500, you might be able to get > > the people who need this service to pay for it. it's worth a try? -- > > Paul Vixie

Re: Points on your Internet driver's license (was RE: Even you can

meone else here reports that his squid proxy is regularly reported by norton's tools because it sets unusual bits in the tcp header. and so on. -- Paul Vixie

yo, sean!! (Re: Points on your Internet driver's license (was RE: Even you can be)

-09-02 | 250 | 63.205.135.210 | 2 2003-08-22 | 249 | 63.201.38.49 | 355 2003-09-22 | 249 | 63.203.72.209 | 325 2003-08-27 | 249 | 63.203.157.78 | 3 2003-08-24 | 249 | 63.207.141.20 | 2 2002-12-28 | 247 | 63.199.186.142 |97 (500 rows) -- Paul Vixie

Re: "Default" Points on your Internet "Re: Re: Re:"

omplain when folks blackhole your customers and otherwise treat you as a chemical polluter, like i treat sean's network. an isp has to take responsibility for the output from their network, and the ones who won't, are going to be treated by their victims as "bad internet neighborh

Re: "Default" Internet "Re: Re: Re:"

y) in their own defense. we can argue about anything else that pleases us, invent all the rules and new technology we want, but it will all come down to treaties between nations. unfortunately, my own nation is so interested in appeasing our spammers that they are unable to provide any leadership in this area. someone else should step up. -- Paul Vixie

Re: Pushing GTLD zones [WAS: Akamai DNS Issue?]

now named as a co-conspirator. if you reply to this message, there's a good chance of your e-mail appearing in court filings at some point.) -- Paul Vixie

Re: Verisign vs. ICANN

> Anything I/we can do to help the cause? not at the moment. i'm not a defendant, just a named co-conspirator.

Re: Verisign vs. ICANN

to be upset about my work on the ICANN Security and Stability Advisory Committee. what their "First Amended Complaint" says about me is that: Paul Vixie is a Site Finder co-conspirator [...]. Paul Vixie is an existing provider of competitive services for regis

Re: Verisign vs. ICANN

> PV> Paul Vixie is an existing provider of competitive services for > PV> registry operations, including providing TLD domain name hosting > PV> services for ccTLDs and gTLDs, and a competitor of VeriSign for > PV> new registry operations.

Re: Verisign vs. ICANN

PP software ("ISC OpenReg"), so there's some overlap with the registry/registrar community that verisign might be thinking of. -- Paul Vixie

Re: Verisign vs. ICANN

up by someone who is not an ambulance chaser before it could have any effect on unbiased objective observers. -- Paul Vixie

Re: Verisign vs. ICANN

up by someone who is not an ambulance chaser before it could have any effect on unbiased objective observers. -- Paul Vixie

Re: Verisign vs. ICANN

the content of the root zone. i can't even get an RR added for the glue NS used by 50 or 60 TLD's. but if i had any influence over the root zone, i would use it to prevent a wildcard from ever being added. (i like my nxdomains straight up, no ice, no soda.) [EMAIL PROTECTED] (Henry

Re: Verisign vs. ICANN

> Just curious. How much would it differ from > > http://www.amazon.com/exec/obidos/redirect?tag=icannwatch-20&path=tg/detail/-/0262134128/qid%3D1041619276/sr%3D1-1 > > and > > http://www.law.miami.edu/~froomkin/articles/icann.pdf as i said, it can't be written by an ambulance-chaser or nobo

Re: Unplugging spamming PCs

ull implementation, the only impact will be to protect domainholders against sender-forgery, at which point the spammers will have to use real domain names they get from .biz at $5 each, and the total spam sent continue to rise month by month. and what a marketing triumph THAT will be. -- Paul Vixie

Re: Attn MCI/UUNet - Massive abuse from your network

ason isn't really valid. Hence the > off-topic-ness of this thread. what about 4) using receiver-side blackholes to make up for lack of sender-side policy you can terminate the thread, but the fact that you and sean aren't willing to disco spewing endsystems is leading to intentional internet instability, and that means sooner or later, this thread will be back, just like always. -- Paul Vixie

Re: Attn MCI/UUNet - Massive abuse from your network

> spamhaus has gotten too agressive. > Its now preventing too much legitimate email. that's funny, really funny. s/spamhaus/maps/ or s/spamhaus/sorbs/ or indeed look at any receiver-side filtering mechanism that gets a little traction, and sooner or later folks will say it's too aggressive and p

Re: BGP list of phishing sites?

long run. that's what everybody always said about MAPS but it didn't happen. the internet is very survivable and the necessary traffic always finds a way to get through. fixing layer >7 problems by denying layer 3 service has indeed proven to be the only way to get remote CEO's to care (or notice). -- Paul Vixie

Re: BGP list of phishing sites?

warning. this is about humans rather than about IOS configs. hit D now.  > >> Also, an "easy fix" like this may lower the pressure on the parties > >> who are really responsible for allowing this to happen: the makers > >> of insecure software / insecure operational procedures (banks!) and > >>

Re: BGP list of phishing sites?

> > It's wholy unfair to the innocent parties affected by the blacklisting. > > i.e. the collateral damage. maybe so. but it'll happen anyway, because victims often have no recourse that won't inflict collateral damage. the aggregate microscopic damage of this kind is becoming measurable and "s

Re: BGP list of phishing sites?

> > the root cause of network abuse is humans and human behaviour, not > > hardware or software or corporations or corporate behaviour. if most > > people weren't sheep-like, they would pay some attention to the results > > of their actions and inactions. > > It's easy to blame the user, and usu

Re: BGP list of phishing sites?

> meanwhile your sister has the hassle of getting southwest to send that > fax, or changing her travel plans. i'm sure glad you're not running my > isp. if i were running your isp, paying customers would get to choose.

Re: BGP list of phishing sites?

> So you think it's futile to try to get software vendors to improve their > products. I suppose I can go along with that to a certain degree. But how > can you expect end-users to work around the brokenness in the software they > use? This seems both unfair and futile. at my aforementioned siste

Re: concern over public peering points [WAS: Peering point speed publicly available?]

g. perhaps i'll eat these words when and if that promotion comes through. meanwhile, disintermediation is still my favorite word in the internet dictionary. i like it when one's competitors are free to do business with each other, it leads to more and better innovation. -- Paul Vixie

Re: concern over public peering points [WAS: Peering point speed publicly available?]

> > i've been told that if i ran a tier-1 i would lose my love for the > > vni/pni approach, which i think scales quite nicely even when it > > involves an ethernet cable through the occasional ceiling. perhaps > > i'll eat these words when and if that promotion comes through. > > meanwhile, disi

Re: Spyware becomes increasingly malicious

you can all understand: "why does that provider's upstream still have bgp peers?" if you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well." -- Paul Vixie

Re: Spyware becomes increasingly malicious

> I think depeering is a bit over the top for this situation, ... if their customer was sucking blood from your customer, and if your peer was taking a cut of the proceeds, would the issues be any clearer? > I guess the big question is, is there anyone (other than those profiting > directly from

plumbers coming down the pipe

the status quo. (i say this even while considering the MAPS RBL as fundamentally in-band and non-radical for its time.) -- Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

that .COM/.NET lacks, and parity was needed. the primary beneficiaries of this new functionality are spammers and other malfeasants, and the impact of having it in many TLD's will be to put downward pressure on TTL's. this all needs to be looked at very carefully. -- Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

cism of domain addition, but let's please not also increase dynamicism of delegation change and domain deletion. -- Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

the whole thing, plus some of the references, rather than assuming that the abstract is well supported by the body. -- Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

> >... so, let's increase dynamicism of domain addition, but let's please > >not also increase dynamicism of delegation change and domain deletion. > > What would be your suggestion to achieve the desired effect that many seek > by lower TTL's, which is changing A records to point to available, l

that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net )

i'd said: > > wrt the mit paper on why small ttl's are harmless, i recommend that > > y'all actually read it, the whole thing, plus some of the references, > > rather than assuming that the abstract is well supported by the body. someone asked me: > Would you happen to have the URL for the MIT

Re: VeriSign's rapid DNS updates in .com/.net

> > the primary beneficiaries of this new functionality are spammers and > > other malfeasants > > ... The primary beneficiaries are all ^ intended > current and future .com/.net domain holders: I'm not talking about intended beneficiaries. I agree with your s

Re: ad.doubleclick.net missing from DNS?

ly some liability for either trademark infringement, tortious interference with prospective economic advantage, and the gods alone know what else. if you do this, keep it to a server you run on 127.0.0.1 and ensure that you are its only user. -- Paul Vixie

Re: ad.doubleclick.net missing from DNS?

Paul Vixie wrote: > on the other hand, if you do this for a nameserver that your customers > depend on, then there is probably some liability for either trademark > infringement, tortious interference with prospective economic advantage, > and the gods alone know what else. if you d

Re: that MIT paper again

i wrote: > wrt the mit paper on why small ttl's are harmless, i recommend that > y'all actually read it, the whole thing, plus some of the references, > rather than assuming that the abstract is well supported by the body. > > http://nms.lcs.mit.edu/papers/dns-imw2001.html here's what i've lear

Re: Verisign vs. ICANN

competitors of VeriSign, a fact the Report fails to acknowledge. For example, Paul Vixie, a member of the committee who is cited three times as evidentiary support for the Committee¡Çs conclusions, fails to disclose that he is the president of Internet Systems Corporation ("IS

Re: SPF again (Re: XO Mail engineers?)

-- we're *close*. real close. the next deployment barrier will be that your parent domain has to register your keys, and in the early days, will probably have an unjustifiably poor cost:benefit ratio for doing so. it will NOT, unless i'm completely confused, be that there are too many RR's. -- Paul Vixie

Re: That MIT paper

what i meant by "act globally, think locally" in connection with That MIT Paper is that the caching effects seen at mit are at best representative of that part of mit's campus for that week, and that even a variance of 1% in caching effectiveness at MIT that's due to generally high or low TTL's (o

Re: That MIT paper

r. others, lower. any study that fails to address these questions is worse than useless. -- Paul Vixie

Re: Verisign vs. ICANN

> ... > Unfortunately, SiteFinder did not have such a destructive effect as we > had all wanted it to have. > ... that apparently depends on what you wanted and what you consider destructive. to me, as a domain holder under .COM, the damage was latent, coming in the form of "unacceptable busines

Re: Verisign vs. ICANN

[EMAIL PROTECTED] (Michael Loftis) writes: > ... > The BIND source was modified in response to CUSTOMERS REQUESTS. ... actually, it was multiple credible threats of codeforking that got this done. (as i explained in the press at that time, "isc cherishes our relevance.") -- Paul Vixie

Re: Verisign vs. ICANN

head, what's to stop the root operators from > circumventing anything Verisign or any other TLD operator does? root server operators don't control the root zone, they only publish it. some combination of itu (via the iso3166 process), icann/iana, ietf/iab, and us-DoC are the folks you'd go to if you wanted a toplevel wildcard. -- Paul Vixie

Re: Verisign vs. ICANN

ion which started this thread you will never find a more tightly woven hive of independence and diversity. the only things all 12 operators have ever been able to agree on are that (1) the root zone should be published with maximum reachability and uptime, (2) the root zone should not be edited by the root server operators, and that, finally, (3) there should never be a (3). -- Paul Vixie

filtering 1918 (was Re: Summary with...: Domain Name System ...)

ve been assuming that it was all vijay's fault. but apparently it's not him. so which one of you isn't filtering 1918 at your edge? (oops, it's all of you, isn't it?) -- Paul Vixie

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

behind some random T1 customer.. encore, encore! if BCP38 is too long and complicated for your management to understand when you ask for additional staff or equipment to turn on u-rpf, there's a shorter (4 pages) executive-compatible document that you should print out and staple to your requ

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[EMAIL PROTECTED] (Paul Vixie) writes: > in the example i posted earlier, i included some numbers from one member of > the "f troop", which showed ~21M packets from rfc1918 space over the course > of ~106 days. that's 241 queries per second. on only one host of many. &g

Re: DNS Blocking

he specific name "localhost" is nec'y because glue searches aren't required to find wildcards.) if you put a zone like that in place on a server that's receiving unwanted queries for some zone, they will soon stop, or not. you win either way -- the queries stop, or you laugh your ass off. -- Paul Vixie

Re: DNS Blocking

i wrote: > > ... confuse and make errors for whoever queries it: > > > >@ SOA localhost hostmaster.localhost > > NS localhost > >localhost A127.0.0.1 > >* MX 0 localhost > > A127.0.0.1 > > > > if you put a

Re: DNS Blocking

ic alternative to running a dns server with deliberately bad zone data. -- Paul Vixie

Re: FBI bust DDoS 'Mafia'

[EMAIL PROTECTED] (Paul Vixie) writes: > ... four times in the last two months, a "life flight" helicopter has ... oops, five times. the helicopter engine noise i was listening to while typing the above, turned out to be another red one from stanford hospital. my apologies to a

Re: DNS Anycast as traffic optimizer?

tion or bandwidth -- BGP is not IGRP (and thank goodness!). if you want a web client to get its web data from the best possible web services host/mirror out of a distributed cluster, then you will have to do something a hell of a lot smarter than incoherent dns. there are open source packages to help you do this. they involve sending back an HTTP redirect to clients who would be best served by some other member of the distributed mirror cluster. -- Paul Vixie

OT- need a new GSM provider

ivately to me, I'll summarize back to the list.) -- Paul Vixie

Re: OT- need a new GSM provider

> You can get most of these phones unlocked from the sim lock > and then flog it on ebay - goes to the time > and effort costs of the aggrevation of dealing with mobile > operators. i plan to send the shattered remains of that phone back to AT&T in case they think that my small claims suit is a

Re: Spammers Skirt IP Authentication Attempts

h--- did you think was going to happen?" -- Paul Vixie

Re: Spammers Skirt IP Authentication Attempts

also immaterial. the fact is, it's coming -- and it's useful, just not for the advertised reasons, or a universal reason. -- Paul Vixie

summary (Re: OT- need a new GSM provider )

i'd asked: > > Anybody had notable (good or bad) billing and/or customer service > > experiences with Voicestream or any other GSM provider with native > > coverage in the San Francisco Bay Area? many people said: > I think Voicestream and T-Mobile are the same company now. If you've > had pr

Re: Spammers Skirt IP Authentication Attempts

> True, but bounces, and anything else with NULL return path, can be taken > care of with SRS. SRS is probably a higher pairwise deployment barrier than SPF. but in any case you should take this argument to the IETF MARID WG, since getting agreement on nanog@ (assuming it's possible) won't stop

who's next?

in we see: Campaigners against spam on the internet have won a major battle against the world's second largest internet service provider. US firm Savvis was allegedly earning up to $2 million a month from 148 of the world's worst sp

Re: Spammers Skirt IP Authentication Attempts

way to rearrange the deck chairs on the Titanic. we won't have decent interpersonal batch digital communications again before whitelists; everything we do in the mean time is just a way to prove that to the public so they'll be willing to live with the high cost of fully distributing trust. -- Paul Vixie

Re: Spammers Skirt IP Authentication Attempts

domain names. i recommend against deployment of anti-spam methodologies whose only guaranteed effect is to force spammers to have to be smarter. (they will!) -- Paul Vixie

"Intel calls for Internet overhaul"

update SAN FRANCISCO--The Internet needs to be upgraded with a new layer of abilities that will deal with imminent problems of capacity, security and reliability, Intel Chief Technology Officer Pat Gelsinger said Thursday. Gelsinger pointed to PlanetLab, an experimental network that sits on top o

Re: Spammers Skirt IP Authentication Attempts

> > you could bet that by closing off this avenue, SPF will force > > spammers to use other methods that are more easily detected / > > filtered, and that if you play this cat&mouse game long enough, it > > will drive the cost of spam so high (or drive the volume benefit so > > low) that it'll jus

Re: 30 Gmail Invites

i just don't get it. the approach shown in <http://www.vix.com/personalcolo/> makes sense to me. the gmail / aol.com / yahoo.com / etc approach does not. -- Paul Vixie

Re: Guts (Was: Drivel about BCP38, et al.)

d-user loops, and being able to do it at all is an expensive luxury -- a dropping tide has lowered all boats. -- Paul Vixie

Re: BCP38 making it work, solving problems

d it before you call multihomed networks an "issue" wrt BCP38 deployment. in fact, you should read it, and BCP38, and BCP84, before participating in this discussion at all, either here, or at the bar-bofs next week. -- Paul Vixie

Re: BCP38 making it work, solving problems

ical communities by that very chutzpah. i agreed but pointed out that the same engineers are here, but with vastly fewer of their buddies to help out, and vastly more supervision from the CFO than used to be the case. HOWEVER, there is still an opportunity to show some leadership, and GET THIS DONE without waiting for fireman's fund and a bunch of ISO9000 wonks to have to recognize it in a corporate risk profile. -- Paul Vixie

Re: BCP38 making it work, solving problems

se sources by looking at the query-names. i've also been wondering if ISC should have a peering agreement requiring peers to implement BCP38. -- Paul Vixie

Re: BCP38 making it work, solving problems

idn't have 50% or more packets coming from spoofed sources, though due to loose-mode uRPF, most spoofed sources in the last year or so have been from addresses for which a route exists. -- Paul Vixie

Re: aggregation & table entries

supposed to happen, you (the upstream) should have to take explicit, non-default action which would probably include a source-address ACL, or static routes, or something. -- Paul Vixie

Re: aggregation & table entries

works, but it doesn't scale very well. Especially where you > really don't know that your customer's customer is doing this. It's 2004, and so, your customers who want to do this have to explain why, and you have to maintain extra-ordinary filters for such customers, at either your cost or the customer's cost. -- Paul Vixie

i've got an extra hotel room for nanog-dc -- anybody need it?

i got the room just before the deadline, it's in the nanog/arin hotel, but i'm not going to make it to DC after all. first come first served; if you wanted to be in the conference hotel but missed the deadline, i can tell the hotel to put the room in your name and you can call them and give them

Re: i've got an extra hotel room for nanog-dc -- anybody need it?

and then auction them off. apparently, lots o' folks don't book their room while there still is one at the group rate. -- Paul Vixie

Re: aggregation & table entries

> > > > And what do you do with a BGP customer which sends you traffic > > > > from prefixes he doesn't want to announce to you? There are such > > > > customers. Fail filter ACL? > > > > > > This has been my question with uRPF from the beginning. You can > > > solve this on for some networks, bu

Re: short Botnet list and Cashing in on DoS

goalset. > Going after the bots is lesser effort. The controllers are a priority. wide scale BCP38 conformity is the only way any of this will ever happen. -- Paul Vixie

Re: short Botnet list and Cashing in on DoS

.. Yea, verily. This is not an impossible problem for this community; it is only an impossible problem for any one of us acting totally independently. And while the solution isn't instant, the tide CAN be turned. -- Paul Vixie

Re: short Botnet list and Cashing in on DoS

i was recently chastised for posting non-operational content to nanog, and so, while i am willing to beat the drum for source address validation, i'm very concerned about commenting further in what has to be the 40th or 50th version of this thread in the last ten years. with trepidation, then: >

Re: short Botnet list and Cashing in on DoS

someone who wished to remain publically unnamed answered me by saying: > I got chastized a little while ago, too, for a single post, and told that > it was my THIRD warning (having not received any at all before). Feh. i can't think of anyone among all nanog posters since the beginning of time w

Re: BCP38 making it work, solving problems

> > ... the first thing is, some nets who want the internet to work this > > way have to implement BCP38 in their own corner of the internet. > > then they have to start de-peering with nets who don't do it, and > > offer a better rate to customers who do it than to those who don't. > > then they

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

a customer of chello.be has been repeating a dns dynamic update against my zone every four minutes since october 20. chello's abuse reporting channel is no doubt full of spam reports. their noc no doubt doesn't care about end-user problems. i nmap'd the offending box: Starting nmap 3.50 ( ht

Re: Important IPv6 Policy Issue -- Your Input Requested

le). i hope that there will be no more ops-relevant specs with harmful potential side-effects and ineffective+unenforceable prohibitions against those. and of course, see BCP38 (or if you're in management, SAC004). -- Paul Vixie

<    1   2   3   4   5   6   7   8   9   >