Re: Sitefinder II, the sequel...

[Chris Woodfield]

Going off on something of a tangent, I'd be really curious what sort  
of efforts OpenDNS are making/will need to make in order to limit  
their servers' utility as a relay for amplification attacks (which  
I'm listening to a discussion on at IETF as I type).


http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are- 
evil-01.txt


On Jul 13, 2006, at 8:08 AM, Patrick W. Gilmore wrote:



On Jul 13, 2006, at 3:39 AM, Simon Waters wrote:

Most of those I know try to deploy recursive services as close as  
possible to

the client, avoiding where possible alternative views of the DNS, and
forwarding.


Would that everyone did what the people you know do.

Unfortunately, there are a few providers doing things like  
outsourcing their recursive service to, say, their upstream, or  
having one "node" of recursive servers anywhere in the world for  
all their end users.  These providers violate the first part of  
your sentence.


The second part doesn't make any sense to me.  It seems that having  
multiple, geographically disparate recursive name servers would be  
more likely to present an "alternative [view] of the DNS".  (In  
fact, I can prove that's true in at least some cases. :)  So you  
are actually arguing -against- your first point.


That said, no one has yet said why it is necessary, or even  
desirable, to have a completely homogenous view of the world.



Perhaps time to ask Brad, Paul and Cricket what they think, and  
have answers

to their comments.


Perhaps.  However, in the last DNS related thread, Paul made a  
pretty strong claim (violating a protocol) and showed exactly  
_ZERO_ facts to back it up, despite being asked at least five times  
(by my count).



With automated responses to "bad things", it is usually best to  
minimise the
scope of the change. Similarly typo correction makes sense for  
URLs, but not
for most other uses of the DNS (hence the proviso you make to  
switch it off
if you use RBL, although I'd say switch it off for all email  
servers less you
start correcting spambot crud, our email servers make a DNS check  
on the
senders domain, that doesn't want correcting either), so the  
answer is
probably browser plug-in (although most browsers already try to  
guess what

you meant to some extent).


Perhaps something as simple as a preference only 'correcting'  
queries that begin with "www"?


--
TTFN,
patrick

Re: BCP for Abuse Desk

[Chris Woodfield]

I've found that the reserving the right to nullroute an offending host's 
IP address for repeated spam offenses is a good intermediate step 
between simple notifications and contract/circuit termination. It lets 
the customer know you mean business while still preserving the 
customer's account status; if the offender is a web hoster, it winds up 
being a particularly effective tool, as the threat of collateral damage 
from other sites hosted on the same IP is pretty compelling.


Of course, it's important to be willing to remove the nullroute as soon 
as the customer confirms that the problem has been dealt with, otherwise 
it does effectively become a partial termination of services.


-C

[EMAIL PROTECTED] wrote:

On Tue, 30 May 2006 20:51:55 CDT, you said:



 3d) Make sure your ToS allows nuking a spamming/abusive host.
 3e) Then *use* that clause in the ToS when needed.


Each of the ISP's I worked for had such a clause.  I felt it
was a double edged sword.  The only choices were to use it or
not to use it, and on non-clear cut cases the business side of
a company may be reluctant to heave a paying customer out the
door.  I would advocate service contracts that allow a graduated
response including, but not limited to, getting rid of the 
customer.  That way, there are penalties available even in cases
of "unintentional" network abuse.  



As I said, "when needed".  As you correctly noted, sometimes it's
more helpful to the bottom line if it remains an unmentioned stick
while you find a carrot to wave at the customer.   If a well-phrased
phone call or two and a helpfully informative e-mail can get the problem
resolved, you obviously didn't *need* to nuke. :)

Re: IP ranges, re- announcing 'PA space' via BGP, etc

[Chris Woodfield]

I would expect some sort of confirmation that Level3 has allocated  
the block to them - if there is no swip or RADB object, the customer  
should request that Level3 create one (or both). If Level3 cannot do  
either (unlikely) I'd request direct contact from Level3 confirming  
the allocation.


-C

On Apr 14, 2006, at 4:26 PM, Andy Davidson wrote:



On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote:

When a random customer (content hoster) asks you to accept
something out of 8/8 that is Level(3) space, and there is no
route at this moment in the routing table, do you accept it,
or does Level(3) have some fancy written formal process and
they get approval to do it, etc.?


Initial instinct has to just be 'yuck', but in the interest of getting
the job done, I'd look at :

 - how is it registered ?  Are your customer mentioned ?
 - is it already a prefix which is announced seperately from the  
rest of

   the aggregated block ?
 - if the customer wants to multihome, have they even considered PI ?
 - are the customer happy for you to talk to the aggregating company ?
   are you happy to talk to them ?
 - it's still 'yuck'.


-a

Re: Common Carrier Question

[Chris Woodfield]

Madison River, a regional cable provider in North Carolina, did it  
last March and got fined by the FCC for its trouble:


http://www.networkingpipeline.com/60405195

-C

On Apr 13, 2006, at 9:16 PM, Alain Hebert wrote:



  Eric Germann wrote:

Except when an ISP blocks Vonage completely, then they aren't  
neutral and it

is QoS (unless the QoS == 0 for VoIP)

   We (or its just me) might be curious about which ISP did that.

   Offlist if you want.

   Thanks.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of

Patrick W. Gilmore
Sent: Thursday, April 13, 2006 6:07 PM
To: NANOG list
Cc: Patrick W. Gilmore
Subject: Re: Common Carrier Question


On Apr 13, 2006, at 5:57 PM, Eric Germann wrote:


I'm working on a graduate policy paper regarding Internet  
filtering by blocking ASN's or IP prefixes.  It is a variation of  
Net Neutrality, just by a different name.




Except Network Neutrality is about QoS, not filtering.


[snip]





--
Alain Hebert[EMAIL PROTECTED]
PubNIX Inc.P.O. Box 175   Beaconsfield, Quebec H9W  
5T7	

tel 514-990-5911   http://www.pubnix.netfax 514-990-9443

Re: The Qos PipeDream [Was: RE: Two Tiered Internet]

[Chris Woodfield]

One thing to note here is that while VoIP flows are low volume on a  
bits-per-second basis, they push substantially more packets per  
kilobit than other traffic types - as much as 50pps per 82Kbps flow.  
And I have seen cases of older line cards approaching their pps  
limits when handling large numbers of VoIP flows even though there's  
plenty of throughput headroom. That's not something LLQ or priority  
queueing are going to be able to help you mitigate at all.


-C

On Dec 16, 2005, at 4:29 AM, [EMAIL PROTECTED] wrote:



A single VoIP call is a rather slim volume of packets compared
to many other uses of the Internet. If a network doesn't have
systemic jitter caused by layer 2 congestion, then one would
expect VoIP to work fine on a modern network. Indeed, that is
what Bill Woodcock reported a year or so ago in regard to
INOC-DBA.

--Michael Dillon

Re: Networking Pearl Harbor in the Making

[Chris Woodfield]

The problem is that generally, things have to get *really* bad before 
people will switch to a more secure infrastructure...it's all about 
costs, and the cost of staying with a less secure platform must 
substantially exceed the cost of switching before it's considered a 
reasonable response. It takes big numbers to overcome intertia.

A decent parallel is gas prices - people didn't stop buying SUVs in 
significant numbers until the price of gas broke $2 a gallon. And it 
wasn't until we hit $3 before people started trading in their Hummers. 
Again, the cost of maintaining the status quo had to get *really* painful 
to overcome the inertia of staying there.

This is already happening on the server side (see the growth rates for 
Linux vs. Windows server software), but it hasn't happened yet there on 
the network infrastructure side, primarily because the 'net has 
yet to see a real large-scale security incident involving network 
hardware. Yeah, Slammer maxed out the flow tables on a bunch of boxes, but 
the routers themselves weren't targets. And swapping out network infrastructure 
in many cases far more costly than migrating server OSes, particularly for 
us folks for whom the network IS our product.

Thus, I feel that it's going to take a wide-scale exploit *of the 
routers themselves* causing large-scale outages before enough people 
switch to make the vendor feel any real pain directly related the failure 
to secure the infrastructure. Only then will we begin to see our 
networks become truly more secure.

-C

On Mon, Nov 07, 2005 at 12:39:31PM -0500, Christian Kuhtz wrote:
> 
> 
> On Nov 7, 2005, at 12:16 PM, Todd Vierling wrote:
> 
> >On Mon, 7 Nov 2005, Christian Kuhtz wrote:
> >
> >>>How so? Haven't we recently seen an across the board bug in
> >>>multiple version of $vendor code?
> >>
> >>And that's evidence of what other than nobody is willing to pay  
> >>for what it
> >>takes to get better code out of $vendor?
> >>
> >>Code can be built better.  It just isn't always economical to do so.
> >
> >In some business models.
> >
> >Financial reports regularly hint that $vendor has margins far  
> >exceeding the
> >costs necessity to clean up security-critical code.  When the  
> >aggregate
> >margins drop thanks to folks choosing $vendor2 because $vendor has  
> >decided
> >to let security flaws stew, it's time for $vendor to reevaluate that
> >business model -- at least a little.
> 
> Apparently they're still in business, and they're making money, and  
> that means people are still buying their stuff.  And as long as  
> that's true, nothing will change.  Correlating a margins over a very  
> large product range with bugs specifically in service provider gear  
> is problematic in my opinion.  Apples v Oranges.  Whatever, it really  
> doesn't matter.
> 
> Reliability should be engineered by the SP, not exclusively expected  
> from any one vendor.  And you can improve reliability by using same  
> devices in a particular fashion, not just by using different devices,  
> which was my whole point about calculating reliability in the first  
> place.
> 
> Thanks,
> Christian
> 
> 

Re: oh k can you see

[Chris Woodfield]

Maybe I'm missing something, but the core issue is that the NO- 
EXPORT'ed anycast instance has a higher localpref inside the AS it's  
being advertised to, and as such supressing the non-NO_EXPORT'ed  
prefix. The "exportable" prefix gets suppressed at a point on the  
network such that the peering routers never see it, so it never makes  
it out of that AS.


Advertising the NO-EXPORT as a /25 (or two /25s) would serve the same  
purpose as tagging it NO-EXPORT, because as you say most peers filter  
on the /25. Incidentally it would obviate the need to assign it a  
higher localpref because it's a shorter prefix. However, unless I'm  
misunderstanding something, the /25 would not preempt the /24  
advertisement, so the /24 would still make it out of the AS.


Just make sure you don't have anything numbered x.x.x.127 on the  
block...


On Nov 2, 2005, at 8:42 AM, Randy Bush wrote:




Is it an idea to have anycasted instances using NO_EXPORT
announce /25's instead of /24's?


many many folk filter on /24, so the /25 would not be seen.


Isn't that the point? The existing /24 is tagged NO-EXPORT after all...


Another possibility is for $LARGE_ISP to localpref the
NO_EXPORTED down to $LOW value


and then how will the down-preffed prefix be seen within
$large_isp?  local-pref is a very heavy hammer.

randy, at the clue edge i guess



-C

ICANN and Verisign settle over SiteFinder

[Chris Woodfield]

Said the flowerpot: "Oh no, not again..."

http://www.businessweek.com/ap/financialnews/D8DEL2TO7.htm? 
campaign_id=apn_tech_down&chan=tc


-C

Re: Katrina could inundate New Orleans

[Chris Woodfield]

This post is very OT, but I think events warrant the protocol  
violation this time. If you're in New Orleans, I'm sure the health of  
the local internet infrastructure becomes secondary to getting your  
ass above sea level...


Looks like a lot of people are going to lose everything in this  
one...If you're one of them, you are in my thoughts.


If you're not in a position to offer first-hand assistance, I would  
recommend making a donation to the American Red Cross' disaster  
relief fund via redcross.org TODAY. The faster they get our money,  
the faster they can be down there helping folks dig out, assuming  
there's a city left to go back to.


If any displaced NANOGers wind up in the Atlanta area, speak up - I'm  
sure there are people here that can offer assistance, maybe a bed, or  
at the very least help you drown your sorrows down at the Vortex Bar  
& Grill...


If nothing else, post and let us know you're okay.

-C

(P.S. This offer not valid if your name is Ronnie Scelson)

On Aug 28, 2005, at 9:10 PM, Fergie (Paul Ferguson) wrote:



Wow. It doesn't look good for New Orleans and surrounding area.

Just curious what measures ISP's in the area may have been going
through in preparation for this (what appears to be huge) hurricane.

- ferg


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Completely off-topic: Sprint Nextel's new logo ....

[Chris Woodfield]

I did see an article a few days ago (can't find the url now) claiming that 
Sprint is planning on focusing purely on wireless and spinning off their 
"traditional" telco/internet operations. I fully expect the spun-off 
company to be acquired shortly thereafter (paging Dick Notebaert...)

-C

On Thu, Aug 25, 2005 at 03:25:04PM -0400, Jeff Cole wrote:
> 
> On Thu, Aug 25, 2005 at 11:57:45AM -0700, william(at)elan.net wrote:
> > On Thu, 25 Aug 2005, Fergie (Paul Ferguson) wrote:
> > 
> > >http://www.engadget.com/entry/1234000243055975/
> > 
> > Isn't that only for Sprint Wireless and has no effect or rest of Sprint?
> 
> There are three logos for the new company. One says just Sprint, one
> says "Sprint, together with Nextel" and one says "Nextel, together with
> Sprint". The official name of the new company is "Sprint Nextel
> Corporation", or so says my last check from them. (Not laid off, went
> elsewhere). The "go to market" name is Sprint. 
> 
> Jeff
> former Nextel worker bee
> 

Re: Verizon Offering Naked DSL in Northeast...

[Chris Woodfield]

Probably to avoid the snafus of the early @Home rollouts, when at least 
one person was accused of stealing cable because the field tech 
installed her cable modem without an RF filter...

http://www.joabj.com/Balt/CableRobbing.html
-C
On Apr 18, 2005, at 5:08 PM, Andy Johnson wrote:
Alex Rubenstein wrote:
What possible technical issue could exist that to don't have to wire 
the dslam to a pots splitter?
Actually, even if they did wire it to a pots splitter, and there was 
no pots line present, it'd still work.
My speculation is that their billing/accounting system is based on a 
POTs number, and since these customers will not need one, they will 
have administrative errors managing accounts.

	Since VZ is doing their FTTP rollout, I imagine they have been tying 
new customers to Physical Addresses now instead, moving away from the 
old POTS based system. Again, all speculation based on how I see the 
DSL/FTTP order process taking place now.

Re: Service providers that NAT their whole network?

[Chris Woodfield]

Apologies for the late reply, but T-Mobile's US GPRS network hands out 
RFC1918 space as well.

-C

On Fri, Apr 15, 2005 at 01:40:12PM -0700, Scott Call wrote:
> 
> On Fri, 15 Apr 2005, Philip Matthews wrote:
> 
> >
> >A number of IETF documents(*) state that there are some service providers
> >that place a NAT box in front of their entire network, so all their
> >customers get private addresses rather than public address.
> >It is often stated that these are primarily cable-based providers.
> 
> In my experience many cellular providers (at least in the US) do this as 
> well.  A GPRS connection to Cingular, even from a laptop device, will get 
> a 1918 address. I don't mind since my phone runs linux with no root 
> password (thanks motorola).
> 
> -Scott

Re: Worms versus Bots

[Chris Woodfield]

I stand corrected, they're out there. I'm advised that 3com has a on-NIC firewall 
product as well.

However, at $299 and $329 respectively, I don't anticipate wide adoption in the 
consumer market...

-C

On Tue, May 11, 2004 at 12:49:05PM -0400, Jonathan M. Slivko wrote:
> 
> Uh... they have. It's called a Snapgear card :)
> -- Jonathan
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Chris Woodfield
> Sent: Tuesday, May 11, 2004 12:42 PM
> To: [EMAIL PROTECTED]
> Cc: Petri Helenius; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Worms versus Bots
> 
> Simple solution...build the on-NIC firewall to not use uPnP, or at least
> require 
> a password before changing rulesets. :)
> 
> Seriously, this is such a stupidly simple solution that I'm amazed no one's
> attempted 
> to make a product out of it yet. 
> 
> -C
> 
> On Tue, May 11, 2004 at 12:21:29PM -0400, [EMAIL PROTECTED] wrote:
> > On Tue, 11 May 2004 11:38:33 EDT, Chris Woodfield said:
> > 
> > > A better solution would be a NIC with a built-in SI
> firewall...manageable from a host
> > > app, but physically separate from the OS running on the PC.
> > 
> > Gaak.  No. ;)
> > 
> > What's the point of a firewall, if the first piece of malware that does
> manage
> > to sneak in (via a file-sharing program, or a webpage that installs
> malware, or
> > an "ooh! Shiny!" email attachment) just does the network Plug-N-Play call
> to
> > tell the firewall "Shield DOWN!"?
> > 
> 
> 
> 


pgp0.pgp
Description: PGP signature

Re: Worms versus Bots

[Chris Woodfield]

Simple solution...build the on-NIC firewall to not use uPnP, or at least require 
a password before changing rulesets. :)

Seriously, this is such a stupidly simple solution that I'm amazed no one's attempted 
to make a product out of it yet. 

-C

On Tue, May 11, 2004 at 12:21:29PM -0400, [EMAIL PROTECTED] wrote:
> On Tue, 11 May 2004 11:38:33 EDT, Chris Woodfield said:
> 
> > A better solution would be a NIC with a built-in SI firewall...manageable from a 
> > host
> > app, but physically separate from the OS running on the PC.
> 
> Gaak.  No. ;)
> 
> What's the point of a firewall, if the first piece of malware that does manage
> to sneak in (via a file-sharing program, or a webpage that installs malware, or
> an "ooh! Shiny!" email attachment) just does the network Plug-N-Play call to
> tell the firewall "Shield DOWN!"?
> 




pgp0.pgp
Description: PGP signature

Re: Worms versus Bots

[Chris Woodfield]

I think running two separate computers is a wee bit of overkill...

A better solution would be a NIC with a built-in SI firewall...manageable from a host 
app, but physically separate from the OS running on the PC.

-C

On Thu, May 06, 2004 at 09:49:37PM +0300, Petri Helenius wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> >
> >you can easily fit an entire router into a PC's slimline
> >case and the router can include a complete SI Firewall
> >capability. The PC BIOS will allow the initial SI Firewall
> >config to be done before booting the PC.
> > 
> >
> 
> They got to it before you did; http://www.giwano.com/
> 
> Pete
> 


pgp0.pgp
Description: PGP signature

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls technologists "biased"

[Chris Woodfield]

At the ISP level, there's nothing inherently wrong with this, IMO; AOL and MSN do it 
already, as does Microsoft. If your customers don't like it, they are capable 
of voting with their checkbooks, particularly with dial service; with cable and 
DSL, the waters are a bit muddier because a cable ISP or LEC could have a captive 
audience.

Verisign's crime against the internet was forcing SiteFinder upon the ENTIRE 
internet, like it or not, and in the process abusing a resource that had been placed 
in their care with the trust that it would not be abused for profit. 

-C

On Mon, Feb 23, 2004 at 10:58:39AM -0500, Randall Pigott wrote:
> 
> I am curious what the operational impact would be to network operators if, 
> instead of Verisign using SiteFinder over all com and net, Verisign or 
> their technology partner for SiteFinder began coercing a large number of 
> independent ISPs and network operators to install their form of DNS 
> redirection at the ISP-level, until all or most of the end-users out there 
> were getting redirected.
> 
> We have been approached by a guy named Mark Lewyn, president Paxfire, Inc., 
> the company he claims created the SiteFinder technology and offerred it to 
> Verisign.  Based here in the Washington DC area, he now also wants 
> individual ISPs to implement his technology of redirection to a web page 
> for unknown domains as a means of earning click-through revenue, and will 
> split the take 50/50 "when Paxfire gets paid"
> 
> As a network operator of a fair-sized regional ISP, as well as operators of 
> arguably the least-expensive nationwide wholesale dial platform for other 
> ISPs to gain nationwide access, we have been approached by Mr. Lewyn on 
> behalf of his company Paxfire Inc.  He wants our company to come have 
> meetings at his law firm's offices, consider accepting and implementing his 
> technology at our local DNS server level, and then supposedly share in the 
> rich profits when customers get redirected, possibly to web pages featuring 
> click-through banner ads.  He says that this is the exact same techology 
> (more accurately, he said that it was evolved one step further, I think) 
> that he sold or licensed to Verisign and that Verisign refers to as 
> SiteFinder.
> 
> Until now, the identity of the technology and marketing partner who created 
> SiteFinder has been kept very confidential, so I was surprised to learn 
> that Mr. Lewyn's company Paxfire Inc. was indeed that partner!
> 
> Further, he claims that Vint Cert himself thinks it is a great idea at the 
> ISP level to do this, and is one of his advisory board supporters.
> 
> Naturally, with the fracas of last Sept 2003, we are hesitant to give up 
> any negative caching, essential anti-spam techniques, and suffer other 
> disruptions that such a redirection service may generate within our 
> networks whenever a non-existent domain request results in a redirection.
> 
> Is there concern to be raised by network operators over such schemes if 
> deployed at the individual ISP level, particularly if such technology 
> becomes widespread?
> 
> Before considering meeting with these guys, we would like to solicit the 
> opinions of this list to be better equipped to say "no" if indeed "no" is 
> the right operational and technological decision for the integrity of our 
> nationwide networks and our interconnection outwards to the rest of the 
> world's networks.
> 
> Thanks most sincerely,
> 
> Randall Pigott
> 
> At 06:11 PM 2/9/2004, you wrote:
> 
> > From Dave Farber's IP list...
> >
> > ---
> >
> >
> >http://www.washingtonpost.com/wp-dyn/articles/A25819-2004Feb9_2.html
> >
> >VeriSign Reconsiders Search Service
> >
> >"Site Finder was not controversial with users, 84 percent of whom said
> >they liked it as a helpful navigation service," said Tom Galvin,
> >VeriSign's vice president of government relations. "We continue to look
> >at ways we can offer the service while addressing the concerns that
> >were raised by a segment of the technical community."
> >
> >Galvin said that the continued opposition stems from "an ideological
> >belief by a narrow section of the technological community who don't
> >believe you should innovate the core infrastructure of the Internet."
> >
> >Critics also claim that VeriSign must run the domains as a public
> >trust, not a profit-making opportunity. VeriSign is the sole operator
> >of the dot-com and dot-net registries under a contract with ICANN.
> >
> >"I don't begrudge them their profit, but someone in an effectively
> >regulated monopoly position shouldn't use their power for their own
> >profit, beyond the terms under which the community gave it to them,"
> >said Steven Bellovin, co-director of the Internet Engineering Task
> >Force's Security Area.
> >
> >Paul Rothstein a law professor at Georgetown University and a paid
> >VeriSign consultant, said that the critics have some legitimate
> >objections but others are motivated by th

[carolw@merit.edu: NANOG 30 Meeting Information]

[Chris Woodfield]

Can someone make sure that a proper supply of torches and pickaxes is requisitioned 
for 
the excusrsion to Boca Raton?

-C

- Forwarded message from Carol Wadsworth <[EMAIL PROTECTED]> -

Envelope-to: [EMAIL PROTECTED]
Delivery-date: Tue, 16 Dec 2003 13:50:11 -0500
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: Tue, 16 Dec 2003 13:48:50 -0500
From: Carol Wadsworth <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: NANOG 30 Meeting Information
X-Mailer: Mulberry/2.1.1 (Mac OS/PPC)
Precedence: bulk
X-Loop: nanog
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
tino.semihuman.com
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
version=2.60


Registration is now open for NANOG 30, February 8-10, 2004,
in Miami.  The meeting will be hosted by Terremark Worldwide,
Inc.  Join us for NANOG's 10th anniversary celebration:

  http://www.nanog.org/

See you there!

- End forwarded message -


pgp0.pgp
Description: PGP signature

Re: Verisign to sell Network Solutions

[Chris Woodfield]

So...correct me if I'm wrong here...does this mean that the registry services 
operations and the GTLD maintenance operations for .com/.net will be owned by 
different companies?

Isn't that what we wanted all along?

-C

On Thu, Oct 16, 2003 at 10:58:11AM -0400, Adam C. Greenfield wrote:
> 
> Yea, looks like (after a brief reading of the press release on their
> site) that they are just selling their registrar business off, but will
> still be the people maintaining the com and net registries.
> 
> On Thu, 2003-10-16 at 10:29, Mark Radabaugh wrote:
> > This is interesting:
> > 
> > 
> >   Dear Valued Network Solutions Customer,
> > 
> >   Today VeriSign, Inc. announced that it has entered into a definitive
> > agreement to sell Network Solutions to a new entity formed by Pivotal
> > Private Equity.
> > 
> > 
> > Mark Radabaugh
> > Amplex
> > (419) 720-3635
> > 
> > 
> > begin 666 clear.gif
> > K1TE&.#EA`0`!`( ``"'Y! $`+ `!``$```("1 $`.P``
> > `
> > end
> -- 
> Adam C. Greenfield ([EMAIL PROTECTED])
> Senior Systems Engineer
> JTL Networks Inc.  (614) 847-9790
> 
> 
> 
> 


pgp0.pgp
Description: PGP signature

Re: Address for making BGP changes w/ Qwest?

[Chris Woodfield]

On Thu, Sep 04, 2003 at 10:18:49AM -0500, Gerardo Gregory wrote:
> 
> The only way I have gotten them to make BGP changes was through their 
> qwestsource website, and filling out their form. 
> 
> https://qwestsource.net/qwestsource/workTemplate.jsp 
> 
> hope it helpsgood luck! 
> 

s/helps/works

-Chris

Re: relays.osirusoft.com

[Chris Woodfield]

IIRC, it was Ron Guilmette who did this for a BL zone he was operating a long time 
ago, 
but it happened six months or so after he had deactivated the zone and was still 
getting numerous queries for it. So he reactivated the zone, answering 127.0.0.2 for 
every query, to get those people to stop. He also posted his intentions to SPAM-L 
and NANAE at least a few weeks in advance. Still a BOFHish move, but at least there 
was 
plenty of warning.

-C

On Wed, Aug 27, 2003 at 01:36:54PM -0400, Nathan J. Mehl wrote:
> 
> In the immortal words of Richard Welty ([EMAIL PROTECTED]):
> > 
> > On Tue, 26 Aug 2003 15:25:46 -0700 (PDT) "Gary E. Miller" <[EMAIL PROTECTED]> 
> > wrote:
> > > returning 127.0.0.2 for everything would be an ugly way to bow out.
> > 
> > yes, but it's been done before.
> 
> And oddly enough, it was a terrible idea the first time, and hasn't
> gotten any better in the intervening months.  I suppose going down in
> a blaze of glory might be appealing in the sleep-deprived haze of the
> tail end of a multi-week DDOS attack, but PLEASE.  Null-route the
> netblock and be done with it.  Returning 127.0.0.2 for every query
> does NOTHING but convince more people that volunteer blacklist
> providers like SPEWS are more trouble than they're worth.
> 
> -n
> 
> <[EMAIL PROTECTED]>
> "Must I pray in Hebrew?" No, and wipe that look of terror off your face. 
> Fluency in Hebrew, of course, is vital to the proper understanding of Israeli 
> truck driver insults. (--David Bader, "How to Be an Extremely Reform Jew")
> 


pgp0.pgp
Description: PGP signature

Re: "The internet is slow"

[Chris Woodfield]

Didn't most of us just do that a couple weeks ago?

-C

On Thu, Jul 31, 2003 at 04:03:12PM -0500, [EMAIL PROTECTED] wrote:
> 
> Rebooting the Internet once a month might prevent future problems.
> 
> Power off, count to ten, then restart...Proactive Management!?
> 
> Jack
> 


pgp0.pgp
Description: PGP signature

Re: Don't call registry off the map?

[Chris Woodfield]

Making a telemarketing call to a cellphone is already illegal. I think it's under the 
same law that forbids junk faxes.

-C

On Fri, Jun 27, 2003 at 12:53:32PM -0400, Andy Dills wrote:
> 
> On Fri, 27 Jun 2003, Andy Dills wrote:
> 
> >
> > On Fri, 27 Jun 2003, Patrick wrote:
> >
> > >
> > >
> > > Can anyone reach www.donotcall.gov? Seems to be off the map...
> >
> > Everything's fun and games until somebody posts to Slashdot...
> 
> But then, the site loads very quickly for me now.
> 
> I have an important question, and I know NANOG isn't quite the perfect
> place for it, but this is an issue that possibly affects many of you, and
> isn't addressed on their site.
> 
> 
> I don't currently get soliciting calls on my cell phone. My cell phone is
> my only phone. If I sign up for the donotcall list, will that just enable
> the exempt organizations to harvest my number to call me?
> 
> I'm not so sure I should sign up.
> 
> Andy
> 
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
> 


pgp0.pgp
Description: PGP signature

Re: [NANOG-LIST] Sprint VS. Qwest

[Chris Woodfield]

"Dude, where's the core?"

(ducks)

-C

On Wed, Oct 16, 2002 at 04:27:46PM -0700, Brent Van Dussen wrote:
> 
> The latest (april 2002) Skitter data shows sprint being slightly closer to 
> the internet core than qwest.
> 
> Check it out:
> 
> http://www.caida.org/analysis/topology/as_core_network/pics/ascoreApr2002.gif
> 
> -Brent
> 
> At 04:23 PM 10/16/2002, Christopher K. Neitzert wrote:
> 
> >List,
> >
> >Neither Sprint nor Qwest are serious about earning my business and are not
> >providing me with their network peering details.  I was hoping that the
> >list might have the collective resources to help me determine who has
> >better peering.
> >
> >thanks
> >
> >chirstopher
> >
> >
> >--
> >Christopher K. Neitzert / 0xC10D222F / [EMAIL PROTECTED]
> 
> 



msg06093/pgp0.pgp
Description: PGP signature

Re: AT&T NYC

[Chris Woodfield]

That's why you configure two. :)

-C

> looking a lot better than configuring 4 more BGP sessions.  I've heard
> some people recommend a route-reflector, but that would mean if the
> route-reflector goes down you're screwed.
> 
> -Ralph
> 
> 



msg04911/pgp0.pgp
Description: PGP signature

Re: Max Prefixes Configured on Customer BGP

[Chris Woodfield]

That's why you make sure that any incidents where max-prefix is tripped is 
caught by a syslog watcher and brought to the immediate attention of whoever's 
sitting in your NOC. Honestly, if all you're dealing with is customer BGP 
session, I would propose that 90% of them don't advertise more than 10 prefixes, 
so a max-prefix number higher than, say, 100 should do for most cases. And for 
that last 10%, max-prefix is a per-session configuration, so that number can always 
be set higher. IMO, advertising 100 routes for 30 seconds is far less damaging 
than 8000 routes.

Also, don't forget about the warn option - if a customer's organic growth puts 
them close to the prefix limit, you should get a heads-up in most cases.

I recall an incident where we brought up a customer advertising around 600 
routes, and sent the prefix list our upstream, who dutifully added all 
600 routes to the prefix list, but neglected to raise their maximum-prefix limit 
from 300. This, of course, had predictable results. Doh.

-C

> This isn't a terribly cisco-specific reply so I'll keep it here.
> 
> The problem with restart systems (btw thank you cisco for finally adding
> this)  is, think about how much damage can be done by announcing 8k routes
> for the 30 seconds (or 5-10 minutes if there is a Foundry in the mix :P)
> before you get to the limit and kill the session. Now add in the damage 
> caused by this happening every 15 minutes, and the dampening. Or even 
> worse, someone who turns up more routes and happens to hit right around 
> the exact number or close to it. Imagine a session which goes over by 1 
> route, trips, stays down for 15 minutes, comes back up and this time has 1 
> less route, and noone notices the prefix limit needs to be raised. You 
> should make sure that the restart time exceeds the number/length of flaps 
> necessary to trigger dampening, which on a connect you transit is pretty 
> darn hard to accurately guess.
> 
> IMHO, using only prefix limits on a customer is actually doing them (and
> the rest of the internet that listens to your announcements) a disservice.
> 
> A better system might be where the session is kept up (or periodically
> polled, if you want to make it obvious to the other party that there is a
> problem) without installing the routes, and kept in a "quarantine" state
> for X amount of time to make sure that things stay below a configured
> number. This would be at least a slightly better way of recovering quickly
> once the "problem" has passed, without mucking things up every 15 minutes 
> in the process.
> 
> -- 
> Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
> PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



msg04437/pgp0.pgp
Description: PGP signature

Re: Evil PGP sigs thread must die. was Re: Stop it with putting your e-mail body in my MUA OT

[Chris Woodfield]

Which is why the "web of trust" exists. And why people do keysignings at NANOG 
events. And why, at least on my mail client, the signature shows the email 
address of its owner. If Scott spoofs and email from me and signs it with his 
key, people will notice.

-C

> If people judge authenticity based on the simple fact that a message is
> signed, that's just as useless. Why wouldn't the spoofed email be signed
> with somebody else's key, to make it past all those people who merely
> check to see if it's signed?
> 
> The _only_ way to verify authenticity is to check the signature. By
> signing every single email sent, you endanger yourself by allowing your
> recipients to judge the authenticity of your emails simply by the
> existence of a pgp signature.
> 
> Therefore, you should only sign emails that contain information important
> enough that verification is necessary, otherwise nobody will check.
> 
> Andy
> 
> 
> Andy Dills  301-682-9972
> Xecunet, LLCwww.xecu.net
> 
> Dialup * Webhosting * E-Commerce * High-Speed Access
> 
> 



msg03582/pgp0.pgp
Description: PGP signature

Re: Bet on with my boss

[Chris Woodfield]

You're thinking of the path trace buffer, and it's 64K, one DS0 channel.

-C

> 
> SONET provides for a (couple?) DS0 channels in the headers.
> 
> 
> Eddy
> --
> Brotsman & Dreger, Inc. - EverQuick Internet Division
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 (785) 865-5885 Lawrence and [inter]national
> Phone: +1 (316) 794-8922 Wichita
> 
> ~
> Date: Mon, 21 May 2001 11:23:58 + (GMT)
> From: A Trap <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Please ignore this portion of my mail signature.
> 
> These last few lines are a trap for address-harvesting spambots.
> Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
> be blocked.
> 



msg02942/pgp0.pgp
Description: PGP signature

Re: remember the "diameter of the internet"?

[Chris Woodfield]

Because most of their backbone architects came from IBI/Digex?

-C

> 
> Why do you think Cogent has ".atlas." in their DNS? :)
> 
> -- 
> Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
> PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



msg02774/pgp0.pgp
Description: PGP signature

Re: Bogon list

[Chris Woodfield]

Well, the biggest offender in this respect by far was @home, and you know what 
happened to THEM...

-C

On Fri, Jun 07, 2002 at 12:55:08PM -0400, Greg A. Woods wrote:
> 
> [ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ]
> > Subject: Re: Bogon list
> >
> > RFC1918 does not break path-mtu, filtering it does tho.. 
> 
> So, in other words inappropriate use of RFC 1918 does not break Path MTU
> Discovery!  You can't still have your cake and have eaten it too.  One
> way or another RFC 1918 addresses must not be let past the enterprise
> boundaries.  Lazy and/or ignorant people don't always meet all the
> requirements of RFC 1918, but it's only their lack of compliance that
> _may_ allow Path-MTU-discovery to continue working for their networks
> for _some_ people _some_ of the time.
> 
> However any enterprise also using RFC 1918, but using it correctly (or
> customers of such an enterprise), and thus who are also carefully
> protecting their use from interference by outside parties, will be
> filtering inbound packets with source addresses in the RFC 1918 assigned
> networks, and so as a result they _will_ experience Path-MTU-discovery
> failure (i.e. at any time it's necessary it literally cannot work) when
> attempting to contact (and sometimes be contacted by, depending on the
> application protocol in use) any host on or behind the lazy and/or
> ignorant operator's network(s).
> 
> (and no, I'm not sorry if I've yet again offended anyone who might be
> mis-using RFC 1918 addresses for public nodes -- you should all know
> better by now!  How many _years_ has it been?)
> 
> > > 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
> > > (of which an exchange would be a boundary)
> > 
> > What for? You'll find many more much more mailicious packets coming from
> > legit routable address space.
> 
> If you have any IP address level trust relationsips on your internal
> LANs then you _MUST_ (if you want those trust relationships to be valid)
> filter all foreign packets with source addresses appearing to be part of
> your internal LANs.
> 
> > For p2p you can use unnumbered.. it wont work on exchanges but i agree
> > they shouldnt be rfc1918. 
> 
> On this we can agree!  :-)
> 
> -- 
>   Greg A. Woods
> 
> +1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>



msg02540/pgp0.pgp
Description: PGP signature

Re: operational: icmp echo out of control?

[Chris Woodfield]

The problem here is that other types of probes raise IDS alarms on way too many 
networks - the next-best method is to probe HTTP ports, but we don't want to 
have to pull down thousands of web pages just to get performance stats. So, 
they send a SYN, wait for the ACK, record the latency and send a FIN. 
Sounds benign, but you'd be surprised how klaxons go off in response to this.

-C

> Perhaps most maddening is that ICMP echo/response hardly reflects
> real-world performance.  (At least I don't usually tunnel my
> HTTP, SMTP, and FTP packets through ICMP, but perhaps I'm just
> being weird again.)
> 
> 




msg02284/pgp0.pgp
Description: PGP signature

Re: BGP route explosion

[Chris Woodfield]

Has it been established yet where the extra prefixes came from?

-C

On Wed, May 01, 2002 at 03:31:26PM -0400, Andrew Herdman wrote:
> 
> We saw at least an extra 10k prefixes, the router is/was configured to stop at 120k 
>prefixes, little did I know that it would shutdown the BGP session at that point.
> 
> Thanks for the info.
> 
> Andrew
> 
> On Wed, May 01, 2002 at 08:50:55AM -0400, Toan Do wrote:
> > How many extra prefixes did u see?  We saw about 10k prefixes more than
> > normal
> > 
> > Toan
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Wednesday, May 01, 2002 8:42 AM
> > To: [EMAIL PROTECTED]
> > Subject: BGP route explosion
> > 
> > 
> > 
> > I had a network outage this morning brought about by a BGP route
> > explosion at around 6:30 EST(-4) this morning.  Anyone else notice it,
> > and who the culprit whats?  I got the exact same hit from both my
> > providers, AT&T Can, and Telus.
> > 
> > Thanks
> >   Andrew
> > 



msg01300/pgp0.pgp
Description: PGP signature

Re: Qwest Transit

[Chris Woodfield]

Um, wha?

There are providers that will do "one-way" billing (charging less per Mb/s 
in one direction than the other), but the majority of usage-based transit 
services are sold without regard to which directino the highest traffic 
goes.

Now peering, that's a different story. Peering partners, for better or for 
worse, will get snippy if in/out traffic ratios are out of whack.

-C

On Mon, Apr 08, 2002 at 07:48:49PM -0700, Gironda, Andre wrote:
> 
> 
> All ISP's selling transit ask for strict traffic ratios.
> How often do you think they get what they ask for?  I
> would guess not very often.  People like flat rate 95th%
> with no minimal commitment (both the seller and buyer)
> because that's easy to keep track of.  Simplicity is king,
> again.
> 
> Cogent's deals were to make things easy, right?
> 
> I don't know what they charge, but anyone can see that
> an offer like 100Mbps for $10,000 a month makes sense
> in terms of simplicity (not saying it makes sense in
> terms of a transit provider making any money, tho) ;>
> 
> -dre
> 
> > -Original Message-
> > From: Daniel Golding [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 08, 2002 6:52 PM
> > To: 'Alex Rubenstein'; 'Gironda, Andre'
> > Cc: 'Andy Dills'; [EMAIL PROTECTED]
> > Subject: RE: Qwest Transit
> > 
> > 
> > Hmm. Cogent does require some semi-strict traffic ratios to get the
> > really good deals. If it's not violating an NDA, is Qwest asking for
> > similar ones, these days?
> > 
> > - Dan



msg00774/pgp0.pgp
Description: PGP signature

Re: Load balancing in routers

[Chris Woodfield]

If by "round-robin" you mean by destination only, then this is correct. However, if 
you strict per-packet load sharing regardless of flow, then CEF does have this 
capability, although the default behavior is the flow-based load sharing you describe. 

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/switch_c/xcprt2/xccefc.htm#33184

However, IIRC, code stability issues have plagued this feature in many IOS 
releases; I recall Intermedia selling a "bonded T1" product that used this feature, 
and 
supporting it was...not pleasant.

-C

> We used CEF in 11.x and it behaved the same way.  It was never round-robin
> in any way we could observe.



msg00735/pgp0.pgp
Description: PGP signature

Re: Qwest Support

[Chris Woodfield]

I think the main point here isn't the fact that the poster's routing was, in fact, 
not set up properly; it was the fact that he was unable to get a live body at Qwest 
to check it out.

-C

On Thu, Apr 04, 2002 at 06:24:53PM -0500, Daniel Golding wrote:
> 
> I suppose. Except it's not even certain you were having a problem of any
> kind at all.
> 
> Qwest's presence or absence from public IX's really has nothing to do with
> your routes being announced. In fact, Qwest privately peers with all the
> other large networks. While there are many peering sessions at the public
> NAPs, most traffic is carried over private network interconnects, at least
> domestically. Certain peering points in Europe (Linx), tend to run the other
> way.
> 
> In fact, if Qwest were publically peering with other networks, it might be a
> reason why your routes through UUNet were being prefered - private peer
> originated routes are almost always assigned higher local preferences in
> carrier networks, then public peer originated routes.
> 
> I'm not sure your annoyance with Qwest has any basis in their lack of
> performance, as far as IP routing. BGP decision rules and other networks'
> routing policies will govern which paths are used for your routes. Here is
> an example...
> 
> - Network X peers with UUNet in 8 locations. Network X also peers with
> Qwest, lets say in 6 locations. For whatever reason, network X chooses
> UUNet's routes to you over, Qwest's. This could be due to local routing
> policy, dictating that 701 routes get a higher local pref. Or AS path
> lengths could be the same, and the decision could be falling to something
> like router ID. Whatever.
> 
> - In general, all the UUNet peering will get treated the same by Network X's
> routing policy. This won't always be the case, but let's say that none of
> the peering links are congested, etc. So, a certain number of paths are
> carried throughout Network X via iBGP. If UUNet's routes "won" at all those
> peering points, you will not see any paths through Qwest on a single carrier
> route server like Nitrous.
> 
> - Route-views, and the like are different animals. They get ebgp multihop
> views from many providers, so you will tend to see paths from many different
> vantage points, and are more likely to see paths from both your upstreams.
> 
> ISPs get a heavy volume of calls every day. While Qwest may not have the
> greatest customer service, it's not like you were actually down or had a
> qwest originated routing issue. If that were the case, my sympathy would be
> greater.
> 
> - Daniel Golding
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Andy Dills
> Sent: Thursday, April 04, 2002 5:43 PM
> To: [EMAIL PROTECTED]
> Subject: Qwest Support
> 
> 
> 
> 
> Wow, Qwest support is indeed terrible.
> 
> Turned up the DS3 today...the connectivity seems fine. I decided to check
> a couple of routeservers (nitrous); all had my much-prepended UUnet
> announcement, but NONE had my Qwest announcement. Not a huge deal, but
> curious to me.  Is Qwest just not at the public peering points? When I
> checked route-views.oregan-ix.net, I felt better, but yet annoyed. Even
> with the prepends, most networks were announcing UUnet's path.
> 
> So I decided to call them and ask...man what a mistake. The guy is like,
> "Ok, hold on, let me get somebody from our IP noc." 10 minutes goes by,
> and he comes back with "Couldn't get anybody in the IP noc, let me try to
> get somebody in your install group" (being that I turned up the DS3
> today). Comes back another 10 minutes later with "Well, I left a message
> for them, but there isn't much I can do. Nobody seems to be answering
> their phone. If somebody doesn't call you back within 30 minutes, here's
> a number to call..."
> 
> So what if my routes were actually hosed? I'd just be screwed because they
> can't get anybody at the IP noc?
> 
> I wait. Nobody calls back within 30 minutes. I call the number he gave me.
> Busy. You gotta be kidding me.
> 
> So I call the main number again, talk to somebody different. She has me
> hold, and then brings some guy on the line "who can help me". I start to
> talk about route servers, and he's immediately like "Woah, this is a BGP
> problem...I can't help you. Let me try to get somebody from the IP noc."
> 
> So, I wait on hold for about 15 minutes, only to be given dial tone.
> 
> Please tell me it isn't always THIS bad?
> 
> Andy
> 
> 
> Andy Dills  301-682-9972
> Xecunet, LLCwww.xecu.net
> 
> Dialup * Webhosting * E-Commerce * High-Speed Access
> 



msg00653/pgp0.pgp
Description: PGP signature

Re: Exodus/C&W Depeering

[Chris Woodfield]

>From the sound of things, it seems that C&W might have been better off migrating 
AS3561 into AS3967, not the other way around ;)

I am assuming that the reasons it's not happening like this are much more political 
than technical.

-C

On Tue, Mar 26, 2002 at 10:18:04AM -0800, Bill Woodcock wrote:
> 
>   On Tue, 26 Mar 2002, Stephen J. Wilcox wrote:
> > You mean Exodus are well connected and C&W limit themselves which gives
> > longer paths and increased latency.
> 
> Longer paths definitely, increased jitter probably, increased latency
> probably, increased loss possibly.
> 
> C&W obviously have to have a lot of peering as well, since it's all they
> have to sell to their customers.  However, their peering tends to be
> limited to a small number of peers to whom they have large connections,
> whereas Exodus had a large number of peers to whom they had medium-sized
> connections.  So the average hop-count and as-path length for the Internet
> as a whole are both increased by this action, and nearly all paths
> increase in length for Exodus customers.  So yes, Exodus customers are the
> big losers in the wake of this.
> 
> -Bill
> 
> 

Re: Exodus/C&W Depeering

[Chris Woodfield]

I'm presuming that Exodus is planning to get the transit they need after this 
depeering via C&W's peering points? If so, this makes a certain amount of sense - no 
need to maintain separate peering circuits; this is probably just a step in the 
eventual assimilation of Exodus' IP backbone into C&W's.

-C

On Tue, Mar 26, 2002 at 11:12:12AM -0600, Chris Parker wrote:
> 
> Well, another round of the depeering battles.
> 
> We received notice this morning that Exodus is depeering at all US public
> exchanges on Friday ( gotta love that notice by the way ).  They are
> also not accepting any requests for private peering ( despite meeting
> the requirements still listed on the peering page ):
> 
>http://bengi.exodus.net/external/peering.html
> 
> They will happily continue to sell transit at said exchanges though, and
> all C&W peering contacts forward to sales ( ain't that cute! ).
> 
> Should be interesting to see how this impacts the ability to reach
> sites hosted at Exodus.
> 
> -Chris
> --
>\\\|||///  \  StarNet Inc.  \Chris Parker
>\ ~   ~ /   \   WX *is* Wireless!\   Director, Engineering
>| @   @ |\   http://www.starnetwx.net \  (847) 963-0116
> oOo---(_)---oOo--\--
>   \ Wholesale Internet Services - http://www.megapop.net
> 
> 

Re: Re[4]: Metromedia Fiber warns of possible bankruptcy :-(

[Chris Woodfield]

IIRC, The terms of the BA/GTE merger agreement with the FTC stipulate that 
Verizon may re-acquire Genuity once they receive approval to market inter-LATA 
services in most (or maybe all, someone refresh my memory) of the states 
where Genuity maintains service points.

Of course, if Tauzin-Dingell passes, this will speed things up 
substantially. :/

-C

On Wed, Mar 20, 2002 at 09:16:53AM -0500, Deepak Jain wrote:
> 
> 
> 
> On Tue, 19 Mar 2002 16:58:46 -0500 Deepak Jain <[EMAIL PROTECTED]> wrote:
> > Since they are defaulting on a $975B note to Verizon, and since they have
> > been saying Verizon does lease dark fiber from them, it would be the
> > easiest
> > thing in the world for Verizon to take control of MFNX.
> 
> > The real question is will they merge it with Genuity?
> 
> 1) $975B seems a tad large
> 
> 2) it was my understanding that Genuity was spun off when GTE merged with
> BA, a requirement imposed by the regulators.
> 
> richard
> 
> 
> 
> 1) Agreed, s/B/M
> 
> 2) I believe Genuity is vastly still owned by Verizon, even though it is
> publicly owned. I don't remember whether they actually maintained a majority
> or maintained warrants to buy the majority of the shares, but the idea is
> the same.
> 
> Both Genuity and MFNX have lots of debt held by Verizon, and this is plenty
> of leverage when one needs to renegotiate their debt covenants.
> 
> Deepak Jain
> AiNET
>