RE: How should ISPs notify customers about Bots (Was Re: DNS Hijacking by Cox)

> Running email abuse desks for about a decade now makes me > tend to agree with you .. and completely unfiltered pipes to > the internet for customer broadband are a pipe dream, most places. If ISPs were able to standardize consumer Internet access services using a gateway box, then the necess

RE: Problems getting Cisco router and Motorola Nextlevel system to work together

> The router is currently configured to use IRB which is a > hybrid process. > The problems is that the IRB process is overloaded and is > dropping traffic faster than it can process it. Which NPE is in this router? Basically, the 7200 has underpowered CPUs and if you force it to process

RE: An Internet IPv6 Transition Plan

> However, what I'm trying to understand is why the motivation > to rapidly go from v4 to v6 only? What are the factors I'm > missing in operating v4/v6 combined for some time? Growth. Lack of IPv4 addresses will put the brakes on growth of the Internet which will have a major impact on revenu

RE: San Francisco Power Outage

> And the stories that the power guy I'm working with tells > about foreign facilities, particularly in middle east war > zones, are really scary... > We fundamentally do not have the facilities problem > completely nailed down to the point that things will never > drop. Level 4 > datacente

RE: An Internet IPv6 Transition Plan

> > Lack of IPv4 addresses will put the brakes on growth of the > Internet > > which will have a major impact on revenue growth. Before long stock > > market analysts are going to be asking tough questions, and > CEOs are > > suddenly going to see the IPv6 light. > > What exactly will cease

RE: Questions about populating RIR with customer information.

> Does anyone have any thoughts on this? Sorry if this is the > wrong place to ask. First of all, this strikes me as a legal and policy decision. For the legal aspects you should ask your lawyer or take it up on a legal blog like http://www.groklaw.net For the policy aspects, you really should

Domain tasting; a load of hot air?

> I'd suggest: > 1) one week latency between registration and entry into the > TLD nameservers. > 2) 50% (of 1-year registration fee) 'penalty' for > cancelling the registration > before it hits the TLD servers. > 3) $250 'surcharge' (to registrant) for 'immediate' > _irrevocable_ r

RE: Domain tasting; a load of hot air?

> > > http://www.icann.org/announcements/announcement-2-10aug07.htm > Is this something where a consensus 'vote' from a larger > group would help? > or one of the letter writing campaigns congress loves so much? My impression is that it will be more useful for many individuals to make their own

RE: Network Inventory Tool

> Does anyone known some tool for network documentation with: > > - inventory (cards, serial numbers, manufactor...) > - documentation (configurations, software version control, etc) > - topology building (L2, L3.. connections, layer control, ...) We've been using a modelling tool called WANDL w

RE: Re: inter-domain link recovery

> Thank you for comments. I know there are economic/contractual > relationships between two networks, and BGP cannot find a > path that the business rules forbid. But when in these > cases, how to recover it? The network operators just wait for > physically reparing the link or they may manu

RE: inter-domain link recovery

> I think the real question given the facts around this is > whether South East Asia will look to protect against a future > failure by providing new routes that circumvent single points > of failure such as the Luzon straights at Taiwan. But that > costs a lot of money .. so the futures not h

RE: Discovering policy

> Section 5.1 of the updated version of 2821 allows A or > when there is no MX. This allowance must become obsolete and > the process ends when there is no MX record. This idea is fundamentally flawed. There is an assumption in the Internet that email is a universal service. In otherwor

RE: Extreme congestion (was Re: inter-domain link recovery)

> In many cases, yes. I know of a certain network that ran with > 30% loss for a matter of years because the option didn't > exist to increase the bandwidth. When it became reality, > guess what they did. How many people have noticed that when you replace a circuit with a higher capacity one,

RE: Extreme congestion (was Re: inter-domain link recovery)

> The TCPs don't slow down. They use the bandwidth you have > made available instead. > > in your words, "the traffic on the new circuit is suddenly > greater than 100% of the old one". Exactly! To be honest, I first encountered this when Avi Freedman upgraded one of his upstream connections

RE: SNMP Trap Alarm?

> Ok, I could have picked a better title. I'm looking for a > pointer to a box (pref. an embedded platform of some kind) > that will receive/accept SNMP traps and sound a real world > alarm/siren/klaxon. It can do fancy things like logging and > such, but not strictly required. The Google key

RE: An informal survey... round II

> Consider large ISP's that can no longer obtain from the large > blocks (e.g. /12 to /16) but instead must beg/barter/borrow > blocks from others which are several orders of magnitude > smaller (e.g. /16 through /24) every week to continue > growing... such obtained blocks would be announce

RE: An informal survey... round II

> > People keep saying that there is no business case for IPv6 when the > > answer is staring them in the face. Growing revenue is the absolute > > fundamental core of any business case, and in telecom > companies that > > is generally directly tied into growing the network. > > Can you point

RE: An informal survey... round II

> > Considering > > Verizon's highly-connected position at the core of the IPv4 > Internet, > > I would think that all it takes to cause a snowball effect, is for > > Verizon to start offering IPv6 transit and peering on the > same terms > > as IPv4. If there is any company whose IPv6 plans w

RE: An informal survey... round II

> > If there is any company whose IPv6 plans we should be > interested in, > > it is Verizon. > > AKA UUNET? They've been doing IPv6 for _years_. I got my > first IPv6 tunnel from UUNET Netherlands way back when. But when will all of Verizon, not just the UUNET parts, offer IPv6 transit and p

RE: Using Mobile Phone email addys for monitoring

> Is SMTP to a mobile phone a fundamentally flawed way to do this? Yes. It takes too long and nobody is responsible for making sure it is fast. SMS is better, even though it can also suffer from delays, because somebody is in charge of making sure it is fast. The worst delays I witnessed were o

RE: Anyone using uvlan out there?

> Using the libpcap (winpcap for windows users) library, uvlan > listens to a specific ethernet device. If a broadcast frame > is seen, then it is sent off to all the peers so they can add > it to their records and emit the broadcast on their local > network. I doubt that we will be deployi

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

> - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 How? > - setup a Teredo Server + Relay and make available the How? > - and/or the better option IMHO, to keep it in control: setup a >tunnel broker and provide your users access to that. For instance >Hexago sells appliances for

RE: Apple Airport Extreme IPv6 problems?

> I think we will never move to IPv6 if vendors don't do things > like the one in the Airport. However, in order to make this > "transition" phase where there may be a possible degradation > of the RTT, we need to cooperation of the operators, for > example deploying 6to4 relays in their netwo

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

> >> - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 > > > > How? > > This is reasonably well documented for a Cisco but here's a > minimal sample > config: Thanks. I used your info, and other sources, to put up a page at http://www.getipv6.info/index.php/First_Steps_for_ISPs which descri

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

> When I wrote my book, I mostly looked at Cisco for this, and > apart from Cisco to FreeBSD and Linux. The logic is that on a > Cisco, you can build a good tunnel box (6to4 or manual > tunnels) on a C7200 or some other box that has a decent CPU > that can do the tunneling in software. Quite p

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

> Just stumbled upon this article http://www.networkworld.com/news/tech/2007/090507-tech-uodate.html >Suggested here is that Dual Stack is more attractive than tunneling. Is the advise here based on real life experience or is it a matter of what is good for the goose may not be good for the gande

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

> > If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 > > support, a routing daemon (whatever people think is good > enough) and > > whatever other stuff is "enough" to act as a 6to4 gateway. > > You too can build diskless core2duo software routers for USD $1k. > > What about

RE: ipv6/v4 naming nomenclature [Was: Apple Air...]

> >> Don't come up with any other variants. The above form is > what is in > >> general use around the internet and what some people will at least > >> try to use in cases where a DNS label has both an and > A and one > >> of them doesn't work. > Where did the www.ipv6 and www.ipv4 "s

RE: Long-haul protected services: (was: Re: Bee attack, fiber cut, 7-hour outage)

> I'm forking this thread to complain about vendor L's > international long haul network. Protected Sonet service > (T3). DC to UK. I wonder if anyone is using PWE3 for this kind of service, perhaps in an academic/research environment? It would be interesting to compare notes on outages, latenc

RE: New TransPacific Cable Projects:

> Not to mention that the Taiwan straits earthquake showed a > clear lack of physical diversity on a number of important > Pacific routes, which I know some companies are laying fiber > to address. Anyone who took the trouble to read the two articles knows that one of the two cables is a USA-t

IPv6 Information Wiki

ARIN has set up a wiki at http://www.getipv6.info to publish information that will help ISPs, large and small in implementing IPv6 and migrating to an IPv6 Internet. I have collected info from some recent emails to the NANOG list, and other sources, and published it on the wiki. Since this is a

RE: Access to the IPv4 net for IPv6-only systems

> It's a very different circumstance that we have today with > NAT and it only gets worse as utilization increases. Does it really get worse? Or do the ISPs with the eyeballs point at their 6to4, Teredo, ALG installations and happy customers with IPv6 access lines? And do the ISPs with the cont

RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

> That isn't actually true. I could move to IPv6 and deploy a > NAT-PT box to give my customers access to the v4 Internet > regardless of whatever the rest of the community thinks. > > This whole "debate" is a complete waste of time, Yup. It would be more productive for everyone in the debat

RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

> Well, if 95% of the people in a position to do this think > it's worth repeating this effort for IPv6, my objections > aren't going to stop them. But if the majority or even a > significant minority don't want to play, then IPv6 NAT is > going to work a lot worse than IPv4 NAT. What if o

RE: Why do some ISP's have bandwidth quotas?

> And before anyone accuses me of sounding overly critical > towards the AU ISP's, let me point out that we've dropped the > ball in a major way here in the United States, as well. We've dropped the ball in any place where the broadband architecture is to backhaul IP packets from the site wher

RE: 240/4

> 240/4 is tainted. The fact that some code exist somewhere to > make it work is good, but the reality is that there are tons > of equipment that do not support it. If you believe that, then don't use it. But don't dictate to me and everyone else what we can and cannot use in our networks. I

RE: 240/4

> I'm trying to avoid setting the expectation that 240/4 is > just a simple extension to 10/8 and thus people should use it > *today* when they run out of space in RFC1918. I don't believe you. If you were really trying to "avoid setting the expectation" then you would be communicating with t

RE: 240/4

> the other point as was mentioned later in the thread is that > this buys you very little in terms of time before v4 is gone. On average, it buys everybody very little time. But that assumes that 240/4 is being released as a general solution for everybody. This is not the case. We want to rele

RE: 240/4

> > bureaucratic roadblock. ARIN's failure to allocate 240/4 space to > > THOSE WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to > > un-reserve > > 240/4 space is a bureaucratic roadblock. > > If you use this stuff internally and don't tell anybody about > it and nobody ever know,

RE: 240/4

> Okay, this has descended to a point where we need some fact injection. You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have bee

RE: 240/4

> why on earth would you want to go and hack this stuff together, > knowing that it WILL NEVER WORK Because I have read reports from people whose technical expertise I trust. They modified the TCP/IP code of Linux and FreeBSD and were able to freely use 240/4 address space to communicate betwee

RE: 240/4

> > Consider an auto company network. behind firewalls and having > > thousands and thousands of robots and other factory floor > machines. > > Most of these have IPv4 stacks that barely function and would never > > function on IPv6. One company estimated that they needed > 40 million >

RE: 240/4

> I think Michael's point is that it can be allocated as > "unique space for internal use". i.e. kind of like 1918 > space, but you know your slice of > 240/4 is only used on your network[1]. For that purpose, > it's fine, as long as you determine that all your gear allows it. Not quite. I d

RE: Can P2P applications learn to play fair on networks?

> It's a network > operations thing... why should Comcast provide a fat pipe for > the rest of the world to benefit from? Just my $.02. Because their customers PAY them to provide that fat pipe? --Michael Dillon

RE: Can P2P applications learn to play fair on networks?

> So which ISPs have contributed towards more intelligent p2p > content routing and distribution; stuff which'd play better > with their networks? > Or are you all busy being purely reactive? > > Surely one ISP out there has to have investigated ways that > p2p could co-exist with their netwo

RE: Can P2P applications learn to play fair on networks?

> > > It's a network > > > operations thing... why should Comcast provide a fat pipe for the > > > rest of the world to benefit from? Just my $.02. > > > > Because their customers PAY them to provide that fat pipe? > > You are correct, customers pay Comcast to provide a fat pipe > for THEIR us

RE: BitTorrent swarms have a deadly bite on broadband nets

> The vast bulk of users have no idea how many bytes they > consume each month or the bytes generated by different > applications. The schemes being advocated in this discussion > require that the end users be Layer 3 engineers. Actually, it sounds a lot like the Electric7 tariffs found in the

RE: Can P2P applications learn to play fair on networks?

> Rep. Boucher's solution: more capacity, even though it has > been demonstrated many times more capacity doesn't actually > solve this particular problem. Where has it been proven that adding capacity won't solve the P2P bandwidth problem? I'm aware that some studies have shown that P2P demand

RE: Can P2P applications learn to play fair on networks?

> And of course, if you still believe just adding bandwidth > will solve the problems Joe St. Sauver probably said it best when he pointed out in slide 5 here the "N-body" problem can be a complex problem to try to

RE: Can P2P applications learn to play fair on networks?

> When we put the application intelligence in the network. We > have to upgrade the network to support new applications. I > believe that's a mistake from the application innovation angle. Putting middleboxes into an ISP is not the same thing as putting intelligence into the network. Think Akam

RE: AS 7018 BGP blackhole / AT&T contact sought

> > I am sorry to hear you have encountered difficulties Nathan. Your > > request will be forward to team members within AT&T today for > > assistance. > > Thanks, Ren. I will wait to hear from one of these team > members you referred to. I went to http://puck.nether.net/netops/ and tried t

RE: Creating a crystal clear and pure Internet

> On a more practical/technical level, I'm interested in how > French ISPs that worked on the plan to implement it on their networks? > http://www.culture.gouv.fr/culture/actualites/conferen/albanel/rapportol ivennes231107.pdf I couldn't get a good copy from that URL but I did manage to get one

RE: Assigning IPv6 /48's to CPE's?

> I believe someone posted the ARIN recommendation that > carriers assign out /64's and /56's, and in a few limited cases, /48. > > I can understand corporations getting more than a /64 for > their needs, but certainly this does not mean residential ISP > subscribers, right? Then you misunde

RE: Assigning IPv6 /48's to CPE's?

> So if /64 is "subnet" rather than "node" then the practice of > placing one and only one node per subnet is pretty wasteful. In an IPv6 network, a /64 is the subnet prefix of a single broadcast domain, i.e. a single unbridged Ethernet segment. Within this subnet, there are many /128s which re

RE: Assigning IPv6 /48's to CPE's?

> > No, it gives them 16 bits for subnetting. Everybody gets > > 64 bits for addressing because everybody (except oddballs and > > enevelope pushers) uses a /64 subnet size. Since 64 bits > are more than > > anyone could ever possibly need for addressing and 16 bits is more > > than an end sit

RE: Assigning IPv6 /48's to CPE's?

> Is it even a possibility then? A /48 to everyone means 48 > bits left over for the network portion of the address. > > That's 281,474,976,710,656 /48 customer networks. It's 16 > million times the number of class C's in the current IPv4 > Internet. Am I just not thinking large or long term

RE: Assigning IPv6 /48's to CPE's?

> > I'd rather push for /48 and have people settle on /56 than push for > > /56 and have people settle on /64. > > Again, why the hang-up on 8 bit boundaries? Look, why are we arguing about this? Why not split the difference? If /48 is too big and /64 is too small, let's go halfway and use /56,

RE: ISPs slowing P2P traffic...

> I would be much happier creating a torrent server at the data > center level that customers could seed/upload from rather > than doing it over > the last mile. I don't see this working from a legal > standpoint though. Seriously, I would discuss this with some lawyers who have experience

RE: request for help w/ ATT and terminology

> 2. What's the technical terminology for the request for AT&T > to simply start advertising our netblock called? I'm > wondering if they're not understanding our request. You hit the nail on the head with that question. It's called a purchase order request. You bought vanilla Internet acces

RE: An Attempt at Economically Rational Pricing: Time Warner Trial

> There's a missing piece here. You'd need a way to go from the > 1-gige interfaces that commodity hardware can keep up with to > the 10gige-plus interfaces that the backbone requires. Or you could stick with 1G circuits and rely on wavelengths and laying more fiber to take up the slack. Not to

RE: An Attempt at Economically Rational Pricing: Time Warner Trial

> Yes there are P2P pigs out there but a more > common scenario is the canonical "Little Old Lady in a Pink Sweater" > with a compromised box which is sending spam at a great rate. >Should > she pay the $500 bill when it arrives or would a more prudent > and rational approach be like som

RE: An Attempt at Economically Rational Pricing: Time Warner Trial

> There are symmetric versions for all of those. But ever > since the dialup days (e.g. 56Kbps modems had slower reverse > direction) consumers have shown a preference for a bigger > number on the box, even if it meant giving up bandwidth in > the one direction. > > For example, how many peo

The EU's and Google's official positions (was: EU Official: IP Is Personal)

> In the case the german regulator is dealing with the ip > address is not be considered exclusive of the rest of a data > set. The question is given a commercially valuable dataset > which contains ip addresses what is sufficient to anonymize > the users while maintaining the value of the d

Objection: RE: [admin] Re: EU Official: IP Is Personal

> Folks, we'd like to ask that this thread die a quick and > painful death. It's gone off topic and it seems to have run > whatever short course that it tried. I agree. > While what Europe does > is interesting to us as network operators, this is European > policy and off topic for NANOG.

RE: Peering at Equinix Sanjose

First problem is the name Samsung. This sounds like an electronics manufacturing company, not an Internet Service Provider. > integration of 5 domestic centers and 30 local POP across the country. Second problem. It sounds like you only have 5 data centers and 30 PoPs in the USA. This is not ve

RE: IPV4 as a Commodity for Profit

> Operational comment: Look on the bright side, they may follow > Comcast's example and deploy ipv6 instead! Or they may not, and their share price will suffer as a result. People making the technical decision to stick with IPv4 for their large network are also making a decision to limit the gro

RE: YouTube IP Hijacking

> This candidate list of requirements is for route sources that > North American Operators should trust to propagate long > prefix routes, nothing more, nothing less. All operators already have some kind of criteria which they use to decide whether or not to trust a particular source of route

Secure BGP (Was: YouTube IP Hijacking)

> Right. Everyone makes mistakes, but not everyone is malicious.And > the RIRs and the big ISPs are *generally* more clueful than > the little guys and the newcomers. Note also that secured > BGP limits the kinds of mistakes people can make. If I have > a certificate from my RIR for 192

RE: YouTube IP Hijacking

> the laws of Canada, Mexico and the US are still largely > seperate, and the laws of one do not necessarily follow in another. Not to mention other North American countries such as France(1), Bermuda, Cuba, Haiti, etc., etc. --Michael Dillon (1) The islands of St. Pierre and Miquelon, Martini

RE: YouTube IP Hijacking

> > You _need_ a license to drive a car, fly a plane etc. but until now > > you dont need to show that youre skilled enough to run a border > > router. Good idea? I dont think so. > > My point was that even with a license, accidents still occur. Even with a licence and testing, airline crashe

RE: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

> I don't know why Leo thinks so, but even I can observe the > "extra recurring support cost of having to work through two > stacks with every customer that dials in" as being far > greater than any technology costs in either single-stack > scenario. The 'recurring' part is the real killer.

RE: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

--- Michael Dillon RadianzNet Capacity Forecast & Plan -- BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: [EMAIL PROTECTED] Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com Use the wiki:

RE: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

> I'm told by some folks who run core networks for a living > that while the routers may sling IPv6 packets as fast or > faster than IPv4, doing > so with ACLs, filter lists, statistics, monitoring, etc., is > lacking. > What's worse, the vendors aren't spinning the ASICs (which > I'm tol

Recall: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

Dillon,M,Michael,DMK R would like to recall the message, "cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]".

RE: IPv6 on SOHO routers?

> > Linksys RVS4000 for $119.99 > > Linksys WRVS4400 for $209.99 > Looked at the manual, the only thing I could find regarding > IPv6 connectivity was an option You need the January 11 2008 firmware (or newer) to do IPv6. 6to4 works fine but there is a bug with NAT-PT at present. If you Google

RE: Transition Planning for IPv6 as mandated by the US Govt

> If you're providing content or network services on v6 and you > don't have both a Teredo and 6to4 relay, you should - there > are more v6 users on those two than there are on native > v6[1]. Talk to me and I'll give you a pre-built FreeBSD image > that does it, boot off compact flash or hard

RE: Transition Planning for IPv6 as mandated by the US Govt

> Giving away code and hardware is quite the opposite of > lucrative, let me assure you. Right. I looked at your message and it does not parse very clearly. Given that it is odd for people to offer to give away boxes, let alone quote a price for the box that they are giving away, I thought you w

RE: NXDOMAIN data needed for survey

> > We are looking to purchase NXDOMAIN data for an internet survey. > > your survey sounds more like an ongoing typosquatting > business venture. Doing a Google search with the keywords pay nxdomain data turns up some interesting information. --Michael Dillon

RE: rack power question

> Surly we should be asking exactly is driving the demand for > high density computing and in which market sectors and is > this actually the best technical solution to solve them > problem. I don't care if IBM, HP etc etc want to keep > selling new shiny boxes each year because they are tell

RE: rack power question

> what kind of automation can i deploy that will > precipitate the particulates so that air can move (for > cooling) and so that air won't bring grit (which is conductive)? Have you considered a two-step process using water in the first step to remove particulates (water spray perhaps?) and the

RE: rack power question

> Or perhaps some non-conductive working fluid instead of water. > That might not carry quite as much heat as water, but it would surely > carry more than air and if chosen correctly would have more benign results > when the inevitable leaks and spills occur. HCFC-123 is likely what w

RE: 10GE router resource

> High-rate routers try to keep the packets in an SRAM queue > and instead of looking up destinations in a DRAM-based radix > tree, they use a special memory device called a TCAM. FPGAs can be used to do both SRAM and TCAMs. All that is needed is an FPGA board with 10G or a 10G card with an FPG

RE: cooling door

> Can someone please, pretty please with sugar on top, explain > the point behind high power density? It allows you to market your operation as a "data center". If you spread it out to reduce power density, then the logical conclusion is to use multiple physical locations. At that point you ar

RE: cooling door

> Here is a little hint - most distributed applications in > traditional jobsets, tend to work best when they are close > together. Unless you can map those jobsets onto truly > partitioned algorithms that work on local copy, this is a > _non starter_. Let's make it simple and say it in plai

RE: cooling door

> Eg, I > click on a web page to log in. The login process then kicks > off a few authentication sessions with servers located > halfway around the world. Then you do the data gathering, 2 > phase locks, distributed file systems with the masters and > lock servers all over the place. Your hel

RE: cooling door

> I doubt we'll ever see the day when running gigabit across > town becomes cost effective when compared to running gigabit > to the other end of your server room/cage/whatever. You show me the ISP with the majority of their userbase located at the other end of their server room, and I'll conc

RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))

> The flows are in those boxes, but only for stats purposes > exported with NetFlow/IPFIX/sFlow/etc. Apparently it was not > as fast as they liked it to be and there where other issues. > Thus what exactly is new here in his boxes that has not been > tried and failed before? Roberts is selli

RE: Superfast internet may replace world wide web

> Subject: Superfast internet may replace world wide web > says the solemn headline of Telegraph. Hasn't your mummy told you not to believe everything that you read in the papers? Especially when it involves technology! In any case, there is no new Internet here, just an engineered P2P network (

RE: Internet Reachability

> Anyone noticing any issues reaching sites through their "Internet tubes"? It seems that a Chinese ping-pong ball factory recently started making balls that are slightly larger than the standard size. As a result, ISPs whose tubes are newer, are suffering from pneumatic congestion, kind of l

RE: Problems sending mail to yahoo?

> "dear coo/ceo/whomever: i want approval to send the five folk > who go to nanog, and the five folk who go to maawg, and the > five folk who go to first to *all* go to the new frobnitz > joint conference." > > think that'll fly? Why not? We already solved that problem for the five folk who g

RE: Problems sending mail to yahoo?

> Filtering stinks. It is resource-intensive, time-consuming, > error-prone, and pretty much an example of something that is > desperately flagging "the current e-mail system is failing." Hear, hear! > You want to define standards? Let's define some standard for > establishing permission to

RE: Abuse response

> The boilerplate is no damned use. PIRT - and you - should be > focusing on feedback loops, and that would practically > guarantee instant takedown, especially when the notification > is sent by trusted parties. > > > Again, our success rate is somewhere in the 50% neighborhood. > > With

RE: Calling TeliaSonera - time to implement prefix filtering

> We're currently receiving the following prefix from > TeliaSonera on one of our IP transit links in Oslo: > aut-num:AS29049 > as-name:Delta-Telecom-AS > descr: Delta Telecom LTD. > descr: International Communication Operator > descr: Azerbaijan Republ

RE: Abuse response

> - Automation is far less important than clue. Attempting to > compensate for lack of a sufficient number of sufficiently- > intelligent, experienced, diligent staff with automation is > a known-losing strategy, as anyone who has ever dealt with > an IVR system knows. Given that most of us use

RE: Calling TeliaSonera - time to implement prefix filtering

> >> aut-num:AS29049 > >> and *of course* they don't own 62.0.0.0/8. > > > > Own!? > > I think he was saying that Delta Telecom don't *own* > 62.0.0.0/8 and therefore shouldn't be advertising it. > Following that Telia shouldn't be accepting the route and > then re-announcing it to p

RE: Abuse response [Was: RE: Yahoo Mail Update]

> So, to bring this closer to nanog territory, it's a bit like > saying that all the sales and customer support staff should > be given enable access to your routers and encouraged to run > them on a rotating basis, so that they understand the > complexities of BGP and will better understand t

RE: Abuse response [Was: RE: Yahoo Mail Update]

> So how do the little guys play in this sandbox? 3rd-party aggregation. Where do RBLs get there data? They act as a 3rd party to aggregate data from many others. > - It needs to be simple to use. Web forms are a non-starter. If you have the ability to accept reports via an HTTP REST applicati

Re: Anyone from BT...

> ...on the list who might be able to comment on how they/you/BT is > detecting downstream clients that are bot-infected, and how exactly > you are dealing with them? Unfortunately, the way you phrased that question is rather "journalistic" and in BT, as in most large companies, employees are

RE: Google wants to be your Internet

> We also see this with extranet/supply-chain-type connectivity > between large companies who have overlapping address space, > and I'm afraid it's only going to become more common as more > of these types of relationships are established. Fortunately, IP addresses are not intended for use on

RE: Google wants to be your Internet

> The problem is that you can't be sure that if you use RFC1918 > today you won't be bitten by it's non-uniqueness property in > the future. When you're asked to diagnose a fault with a > device with the IP address 192.168.1.1, and you've got an > unknown number of candidate devices using that

  1   2   >