July 2000 - Test - lists.nanog.org

RE: RFC 1918
by rdobbins＠netmore.net 16 Jul '00

16 Jul '00

>If people don't want whiners niggling them about the RFC 1918 addrs >showing up in traceroutes, they should just put RFC 1918 filters on >their borders, so that the whiners simply won't get returns to their >traceroutes. >-Bennett I don't know if denying folks the use of legitimate testing tools due to deliberate misuse of RFC 1918 addressing - after all, its title is 'Address Allocation for Private Internet' - is such a hot idea. To quote from the RFC: With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. I don't see much ambiguity there concerning the intent of the authors, nor the IETF in accepting their premises. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

1 0

RE: slashdot slashdotted?
by rdobbins＠netmore.net 16 Jul '00

16 Jul '00

Slashdot get DoSed with some regularity. They used to talk about it, but then I guess they figured that was only encouraging the lusers, so they generally don't mentioned it, any more. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Steve Sobol [mailto:sjsobol@NorthShoreTechnologies.net] Sent: Sunday, July 16, 2000 8:52 AM To: John Payne Cc: nanog(a)merit.edu Subject: Re: slashdot slashdotted? John Payne wrote: > A couple of people lost access last night... not long after several > messages went out about the Yesmail vs MAPS story... coincidence? yeah, right. MAPS blackholed everyone. :) Cue the black helicopters. -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Pictures of two of my 'children': http://www.WrinkleDogs.com About Spamfighters: "We're not net nazis. We're dot communists." - W. Arnold

1 0

Different customer service reactions (was Re: Wanted: Clueful Individual @ TeleGlobe.net)
by Sean Donelan 16 Jul '00

16 Jul '00

On Sun, 16 July 2000, Troy Davis wrote: > This mirrors my experience with the AT&T NOC on Friday after seeing latency > between GlobalCenter and AT&T. The GlobalCenter NOC had no problem opening a > ticket without caring whether I was a customer or not. They spent a few hours > on it and said it appeared to be an over-loaded AT&T router. > > Not entirely sure of that - and if it was true, wanting to see what AT&T > was doing about it - I called AT&T, was transferred 3 times to reach the IP > folks, and was promptly stonewalled. Interesting, neither company solved your problem, but your reaction was very different to how the different companies handled your call. I guess different companies feel it makes business sense to have such policies. I don't know if it is cultural or what. ISPs which were originally independent companies seem to have more open trouble ticket policies than ISPs formed by telcos. Genuity/BBN and UUNET (I distinguish UUNET from the rest of Worldcom) had relatively open trouble ticket policies. Sprint and MCI had restricted trouble ticket policies. Whats even more interesting is the frustration refusing to even look at a problem creates last a long time. Even if they later fix the problem, it won't make up for the difficulty in getting them to look at it. Sprint blackholed one of my customer's routes for three days, and argued with me for days how it wasn't their responsibility and wouldn't open a ticket. After I eventually proved beyond any reasonable doubt it was in fact a Sprint router making the bogus announcement and got a Sprint engineer to fix their router, to this day I still mention how difficult it is to get Sprint to fix a problem in their network because they'll ignore it as long as they can.

3 2

TE Prez during the Last NANOG
by HANSEN CHAN 16 Jul '00

16 Jul '00

Hi folks, During the MPLS TE panel in the NANOG 19, one of the speakers mentioned the scenario of using LDP at the edge and RSVP-TE in the core. I'm interested to get a copy of the slide (it's not on NANOG website). In particular I'm interested to see the slide showing the label swapping during the transition from 1 signalling domain to the other slide. Does anyone know how to get such a copy? Or could the speaker be kind enough to send me a copy? Thanks, Hansen

1 0

Re: solar storm
by Sean Donelan 16 Jul '00

16 Jul '00

I haven't been tracking outages through an entire 11 year sunspot cycle yet, it only seems like forever. I've looked for correlations of unexplained outages or directly attributable outages with previous solar flare warnings, but so far nothing detectable shows up. There are normal satellite outages twice a year as the sun crosses the Clarke belt. I've also noticed a 3,6,9 year technology obsolence cycle when old equipment fails before companies replace it. On Sat, 15 July 2000, smd(a)clock.org wrote: > Forgive this temporary segue into a potential operational issue. > > http://abcnews.go.com/sections/science/DailyNews/sunspot000714.html > > I would find it interesting if any outages observed by Sean Donelan > or others could be attributed to this solar storm; alternatively, > any higher than average incidence of outages and failures would > be interesting from a correlation analysis perspective.

3 2

Gentle reminder
by Susan R. Harris 15 Jul '00

15 Jul '00

Hi everyone - just a reminder to keep our AUP in mind when you post to the NANOG list: http://www.nanog.org/aup.html We'll keep the number of messages down if we stay with issues that require inter-provider cooperation -- network operations, not politics or other topics inconsistent with the NANOG charter. Your messages are seen by many thousands of people throughout the Internet, and are most useful when they deal with subjects of interest to all. Thanks -- Susan Harris, Merit

1 0

RE: RFC 1918
by Jamie Rishaw 15 Jul '00

15 Jul '00

| I claim rather that most routers _never_ have an operational need | to talk directly to random strangers, i.e. to have their interface | addresses leak. So sure, honor RFC 1918 strictly and utterly and to | the letter: put egress filters for the addrs that would guarantee | that anyone who tried to traceroute through you would see timeouts | as the replies were blocked. If that makes whingers happier, groove | on it. If your router doesn't have any different-MTU interfaces that | it routes between, then there's no harm in using RFC 1918 addresses | on the endpoints of inter-router links. Exactly. I think Vix settled that a few years back when we had this discussion (I dont remember specifically, but I remember occasions when he chimes in, he's usually the closing argument) :-) - RFC1918 addressing on *endpoint* or leaf links, is fine. - RFC1918 addressing on transit links, isn't the best idea, but except for PMTUD (which arguably shouldn't even be, um, an argument) holds no technical reasoning(correct me if i'm wrong) to abstain. My biggest complaint is that RFC1918 addresses for the most part don't have in-addr (and if they do, it's generic) and debugging a problem based on just an IP address is hard when you're talking to cluebies at someone else's NOC. While I'm not suggesting that in-addr be created for RFC1918 specific to each provider's arbitrary allocation of IPs (this would defeat a lot of 1918) I do think that, in a global or public/enterprise network, 1918 addressing on a transit link is just a bad idea. OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net. -jamie

4 5

solar storm
by smd＠clock.org 15 Jul '00

15 Jul '00

Forgive this temporary segue into a potential operational issue. http://abcnews.go.com/sections/science/DailyNews/sunspot000714.html I would find it interesting if any outages observed by Sean Donelan or others could be attributed to this solar storm; alternatively, any higher than average incidence of outages and failures would be interesting from a correlation analysis perspective. In particular, if anyone notices unusual errors or outages affecting long copper lines (e.g. DSL), wireless, and very high density integrated circuits (e.g. in high-end routers or workstations), that would be cool to hear about. Sean.

2 1

piracy on parade
by Paul A Vixie 15 Jul '00

15 Jul '00

Are any mainstream companies signed on with this or is it just chickenboners? ------- Forwarded Message +++++ FOR IMMEDIATE RELEASE +++++ RNDNETWORK ANNOUNCES NEW TLD REGISTRY AND MANAGEMENT SYSTEM Startup developing new, robust domain registry and registration management system and will operate registries for new gTLDs. +++++ July 13, 2000/San Francisco, CA// Internet and research and development community startup RNDNetwork.com Incorporated today announced the development of a comprehensive DNS registry/registration management system for use with new generic Top Level Domains (gTLDs). The new system, developed in conjunction with Strategy Partner LLC (http://www.strategypartner.com ), VRx Network Systems (http://www.vrx.net) anycastNET Incorporated (http://www.anycast.net) @quasar Internet Solutions, Inc. (http://www.quasar.net) and several other Open Root Server Confederation (ORSC) and Top Level Domain Association (TLDA) members, will provide for the two basic functions necessary for the operation of new gTLDs for the Internet. Top Level Domains (TLDs) are the right-most portion of identifiers such as "anycast.NET" and "rndnetwork.COM". Generic Top Level Domains are those available for registration globally, as opposed to those reserved for specific groups and organizations, such as .GOV, which is reserved for the U.S. Government and its agencies. Anyone who has recently tried to register a domain name recently has found that there are very few left that are not cumbersome-the most desirable names are long gone. There is therefore a pent-up demand for intelligible domain names on the Internet, and this demand is far greater than the number of names available in the current gTLDs. "There has been significant work over the last few years to establish operating alternative root systems for new gTLDs", said Ged Gasperas, CEO of RNDNetwork.com Incorporated. "Our intention is to build on the work and intellectual property of our partners, while offering them a system to operate and manage their gTLDs" Gasperas also said RNDNetwork.com intends to operate one of the new gTLDs. "We believe there is significant value in creating an Internet community of research and development groups under the ".RND" gTLD. It's a natural for the Internet." Gasperas said the concept came together while discussing the company's business model and how it applies to the Internet. "Several of our board members brought pieces of the concept to the table. Our discussions led us to our partners, some of whom are operating new gTLDs registries and alternative root servers already." Richard Sexton of VRx Network Services, an industry acknowledged expert on DNS issues, commented on the timeliness of the partnerships. "Groups like the ORSC and TLDA, and others before, have tried to coalesce these efforts with limited success. RNDNetwork has brought the right people together in an open working environment to make it real." VRx Network Services has been operating root zone servers for new gTLDs since 1996. "The problems in the past have been of momentum and need. Both are very much in our favor now." @quasar Internet Solutions president Dena Whitebirch also feels the time has come. "A number of organizations, like ours, have invested a great deal of time and effort to implement DNS registry models. The RNDNetwork effort is a welcome approach that will allow our collective efforts to move forward in a cohesive and sensible fashion." @quasar Internet Solutions, Inc. operates the registry for the .MART gTLD. RNDNetwork.com has also announced their intention to participate in the process for acknowledgment of new gTLDs as set forth by the recently formed Internet Corporation for Assigned Names and Numbers (ICANN, http://www.icann.org) ICANN is attempting to define various criteria and methods for the incorporation of new gTLDs into the Internet's principal root system. "Our business model is designed to succeed. We look forward to working with ICANN and the Internet community to make this a winning proposition for all" said Gasperas. ICANN meets this week in Yokohama, Japan to discuss several key Internet issues, including the potential for new gTLDs. Any system that will support new gTLDs must be functional, sound, and capable of handling a potentially large influx of registrations. Estimates vary, but registration rates in excess of 100,000 per month for some gTLDs is possible. "There are many facets to designing a system of this nature", said Anatoliy Prokhorov, president of Strategy Partner LLC. "Scalability and fault tolerance are absolutely essential. The current DNS root system works. Our model must meet or exceed the current model." Strategy Partner has recently designed several high volume transaction systems, including that for OfficeExpress (http://www.officexpress.com) "We are applying our expertise in high-end transaction systems to the design for the system. This is an exceptional opportunity." RNDNetwork expects the system to be in testing over the next six weeks, with an initial operational model in late August or early September. +++++ Contact Information: RNDNetwork.com Incorporated http://www.rndnetwork.com Ged Gasperas, CEO 1071 Dolores Street San Francisco, CA 94110 (415) 285-9787 fax (415) 285-9788 mailto:gasperas@rndnetwork.com All other organizations can be reached through email from their respective websites. +++++ ------- End of Forwarded Message

9 14

Strange things which should never happen (was Re: RFC 1918)
by Sean Donelan 15 Jul '00

15 Jul '00

In article <Pine.BSF.4.21.0007141956280.95155-100000(a)overlord.e-gerbil.net>, "Richard A. Steenbergen" <ras(a)e-gerbil.net> wrote: > I still have not seen a single compelling arguement which says you gain > one bit more security by filtering RFC1918-source'd packets. It is useless > at best, and disruptive at worst. I don't know my TCP/IP stack well enough, but what happens when a host with multiple interfaces, one of which is assigned an RFC1918 address, receives an packet through another interface with a source address the same RFC1918 address. Are the stacks smart enough to realize the packet is really an external packet, or will they assume the packet came from inside.

2 1