February 2001 - Test - lists.nanog.org

Re: rfc 1918?
by Rancken 23 Feb '01

23 Feb '01

On Thursday, February 22, 2001 10:14 PM, Valdis.Kletnieks(a)vt.edu (Valdis Kletnieks) wrote: That's probably optional. But if you have the router resources to do it. every little bit helps. You probably should filter and log it, to find out why one of your hosts is trying to send to a 1918 address outside your site - if you're not using 1918 space, it shouldn't happen, and if you ARE using it, the packet should have ended up inside your net, not on your border router. Which is quite true, but there are a lot of people out there still using hubs, which (along with improperly configured NATs) probably explains the origins of a lot of this traffic. Which brings me to my point - some of us are actually grateful for having our Private (pun intended) packets filtered while we were setting up a network. John T. Rancken II Rancken(a)Atlantic.net (which is my isp, not where I work :).

1 0

Beer and Gear (Last one by me)
by Ukyo Kuonji 23 Feb '01

23 Feb '01

There is nothing in the Charter that states that I am out of line, nor does it specify a method of removing me from the list. I am not going to continue to carry this any farther, I just want to be certain that the membership knows what is going on. If the membership chooses to be sheep, that's fine. I will leave that alone. Since the Charter does not specify any procedure to modify the operation of NANOG, any action to do so, unless supported by the membership would be handled by the US courts. I am not willing to take that action, nor do I think it needs to be taken. If the membership chooses my proposed option #3, then that's good enough for me. UK PS, Don't insult me by trying to apply filters. I'd just find another way to get through if I wanted to, which I don't. </asshole> --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. On Feb 22 Danny Wrote: Oh, you don't want to play politics but you're certain we need more politics. Actually, you know, perhaps that would be good. Then the membership could vote to tell you that you've been heard, now it's time to shut up. -danny _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

4 3

Re: rfc 1918
by Jim Shankland 22 Feb '01

22 Feb '01

Note that the proposition, "Providers should filter RFC1918-sourced packets at the periphery" is a subset of the proposition, "Providers should filter at the periphery packets with source addresses not explicitly authorized by the provider." I subscribe to the second proposition, and hence implicitly to the former. The problem is not the stray RFC1918-sourced packet here or there. The problem is that the de facto standard is that you can inject packets with arbitrary source addresses into the Internet from anywhere. The number of attacks that use spoofed source addresses is reason enough to change this. But I'm not holding my breath. Jim Shankland

2 1

rfc-1918 has been godwin'd please stop thread...
by Rich Sena 22 Feb '01

22 Feb '01

Folks I distinctly heard a nazi in there... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

1 0

Re: Network for Sale
by Steven M. Bellovin 22 Feb '01

22 Feb '01

In message <038901c09d22$d2736280$7c4cf9d1(a)geeksparadise.com>, "davids" writes: > >> And how does "delay" differ from RTT, except for the obvious constant >> factor? >> >> --Steve Bellovin, http://www.research.att.com/~smb > > The RTT is the sum of two delays. There is no simple way to separate >the two. In general, you don't even know what path the return packets are >taking. This same problem applies to trying to measure packet loss and using >the results to influence routing decisions. I understand that, of course, but since the return path is used for the ACKs that clock the transmissions, I suspect that it's a fair approximation. Paul's response to my posting was quite fair, in fact. --Steve Bellovin, http://www.research.att.com/~smb

1 0

Re: rfc 1918?
by SMcGrath＠dhhs.state.nh.us 22 Feb '01

22 Feb '01

Just had to weigh in on this issue Just look at SANS or CERT, IETF et al and their recommendations for filtering i.e. egress filters should only allow your registered address space and/or networks which you allow to transit your network and ingress filters which filter ALL RFC1918 traffic at your network border. See RFC's 2267,2827 & 3013 Ingress/egress filtering is simply good operational practice which makes the internet a more friendly place

1 0

Nanog-21 people flow analysis
by Lane Patterson 22 Feb '01

22 Feb '01

WARNING: If you are a manager with travel budget cutting approval please read no further: delete this mail NOW! nanog-scan aggregates people packets by their autonomous system names. At Nanog-21 it was used to look at top people flows by company ;-) suggestions for future functionality include categorization of flows into service types such as Vendor, ISP, IXP, EDU, ORG, as well as time-series trending and visualization of past nanogs. as expected from flow data, there is rapid decay of the distribution and a long tail. Cheers, -lane 22 Verio 19 Sprint 19 CiscoSystems,Inc. 16 RiverstoneNetworks 16 GlobalCrossing 14 No Affiliation 14 MFN 10 UUNET 10 Level3Communications 9 MeritNetwork,Inc. 9 AT+T 8 JuniperNetworks,Inc. 8 Equinix,Inc 8 AkamaiTechnologies 7 Pluris 7 EnronBroadbandServices 7 BellSouth 7 ARIN 6 SBC 6 Microsoft 5 WilliamsCommunications 5 NTTCommunications 5 NextHopTechnologies 5 NetRail,Inc. 5 NetAccessCorporation 5 LucentTechnologies 5 JapanTelecom 5 iVMG,Inc. 5 CogentCommunications 5 360networks 4 XOCommunications 4 UniversityofOregon 4 RIPENCC 4 QwestCommunications 4 NortelNetworks 4 NASA 4 InterlinkNetworks,Inc. 4 Interland,Inc. 4 GoldmanSachs 4 Genuity,Inc. 4 FirstWorldCommunications 4 Broadwing 4 AtogaSystems 4 AmericaOnline 3 TeliaInternet 3 TelcordiaTechnologies 3 ReliantEnergyComm.,Inc. 3 QoSNetworks 3 Photuris 3 OptiGlobe,Inc 3 NTTCommunications 3 Logictier 3 InternetInitiativeJapanInc. 3 ExtremeNetworks 3 EpikCommunications 3 CoreeNetworks 3 Concert 3 Charlotte'sNetworks,Inc. 3 Carrier1 3 Cable+Wireless 3 AllegianceTelecom 2 YellowBrix,Inc. 2 Worldcom 2 Villageworld.com 2 Verisign 2 UniversityofWisconsin 2 UnisphereNetworks 2 TTNet 2 TenorNetworks 2 SunGardeSourcing 2 Speedtrak 2 ShawCablesystemsG.P. 2 RenesysCorporation 2 RealNamesCorporation 2 QuarryTechnologies 2 PenTeleData 2 PacketDesign 2 PacketClearingHouse 2 OneSecure,Inc. 2 NovoNetworks,Inc. 2 Nominum,Inc. 2 NacamarDataCommunications 2 MultaCommunicationCorp. 2 i-STTPteLtd 2 InterouteTelecommunications 2 Inktomi 2 IBR 2 iBEAMBroadcasting 2 GoldWireTechnology,Inc. 2 GlobixCorporation 2 GlobalCenter 2 FranceTelecom 2 FoundryNetworks 2 FortPointPartners 2 Exodus 2 Excite@Home 2 EuroNetInternetB.V. 2 DACOMCorporation 2 CoreExpress 2 CircleNet,Inc. 2 ChiaroNetworks 2 CenterGateResearchGroup 2 Callisma 2 Caimis 2 CAIDA 2 CablevisionSystemsCorp. 2 BrixNetworks 2 Bravida 2 AxiowaveNetworks,Inc. 2 AmberNetworks 2 AlliedRiserCommunications 2 AllegroNetworks 2 Aleron 2 AdelphiaBusinessCommunications 1 ZiaNet 1 YipesCommunications 1 XebeoCommunications,Inc. 1 WorldCom 1 WireOneTech. 1 VirtualPhotonics 1 VideotronTelecomLtee 1 ViaNetCommunications 1 Velocita 1 VBCnetGBLtd 1 ValiantNetworks,Inc. 1 ValiantNetworks,Inc 1 USC/ISI 1 UrbanMediaCommunications 1 UniversityofMissouri-KansasCity 1 UnirCorporation 1 TriVergentCommunications,Inc 1 TransNAP,Inc. 1 TokyoTelecom.NetworkCo.,Inc. 1 TiaraNetworks,Inc. 1 TheBurtonGroup 1 TerremarkWorldwide,Inc./NAPoftheAmericas 1 Terabeam 1 TelusAdvancedCommunications 1 Telocity,Inc. 1 TelehouseAmerica 1 TaquaSystems 1 SWITCH 1 SwisscomAG 1 Swisscom 1 SteinbergConsulting 1 SonyCorporation 1 Sonicity,Inc. 1 SigmaNetworks 1 ShawneeLinkCorporation 1 ServerVault 1 RoutingLoopIntergalacticNetworking 1 RoadRunner 1 RedbackNetworks,Inc. 1 RCNInternet 1 rard 1 RackspaceManagedHosting 1 QUEit 1 PSINet 1 ProvidianFinancial 1 ProcketNetworks 1 Pathnet 1 PacketPushers 1 OsakaMediaPortCorporation 1 OnSiteAccess 1 OnFiberCommunications 1 NTTCommunicatins,inc 1 NIKKEI 1 Nextlec 1 NetworkInfrastructureInc. 1 NetigyCorporation 1 NetEffectCorporation 1 NetDestiny,Inc. 1 NERONetwork 1 NECCorporation 1 Navisite 1 NaviSite 1 Napster 1 NAILABS 1 MulticastTechnologies 1 Motorola,Inc. 1 MojoNetworks 1 MitsubishiElectricInfor.NetworkCorp. 1 MirrorImageInternet 1 Micromuse 1 Merike,Inc 1 McLeodUSA 1 MCIWorldCom 1 MazuNetworks 1 Matrix.Net 1 Marnie 1 MarconiCommunications 1 MapleOpticalSystems 1 MahiNetworks 1 LuminousNetworks 1 LondonInternetExchange 1 LightningInternetServices,LLC 1 LaurelNetworks 1 LatencyNetworks 1 KPNQwest 1 KPG,Inc. 1 JetstreamCommunications 1 JENSCorporation 1 IXL,Inc 1 InterWorldCommunications,Inc. 1 InternetMultifeedCo. 1 InternetInitiativeJapanInc 1 InterNAP 1 Intellispace 1 integratelecom 1 INTECWebandGenomeInformaticsCorp. 1 IndependentConsultant 1 Incanta 1 IFXNetworks 1 ICRS,Inc. 1 ICANN 1 H.S.Inc. 1 HSACorp 1 HarvardUniversity 1 GTGroupTelecomServicesCorp. 1 GreenflashTechnologies 1 Google 1 GlobalNAPs 1 GeneralDynamics 1 FujitsuNetworkCommunication 1 Eziaz 1 EugeneSchoolDistrict4J 1 ESnet 1 EpochInternet 1 EnnovateNetworks 1 EnnovateNetwork 1 eDial,Inc. 1 EdgixCorporation 1 EarthSun,L.C. 1 DigitalIsland 1 Digex,Inc. 1 David 1 Datastate 1 DACOMCorp. 1 CWISInternet 1 Curium 1 CosineCommunicationsInc. 1 Coreon,Inc 1 CoradiantInc. 1 ConXionCorporation 1 CIX 1 ChagresVentures,LLC 1 CERT/CC 1 CelerantConsulting 1 CaspianNetworks 1 CalixNetworksInc 1 CaliforniaStateUniversity 1 BroadviewNetworks 1 BroadRiverCommunications 1 BBC 1 AVICI 1 AstaNetworks 1 ArgonneNationalLaboratory 1 ArborNetworks 1 AONNetworks 1 ani+companyInc. 1 Amazon.com 1 AlcatelNetworks 1 Alcatel 1 AlaskaFiberStar,LLC 1 AgilentTechnologies 1 AdvancedTelcomGroup 1 Aduronet 1 AddisonWesleyLongman 1 AcceLightNetworks 1 2600Enterprises

1 0

Re: Network for Sale
by Steven M. Bellovin 22 Feb '01

22 Feb '01

In message <200102212028.MAA50344(a)redpaul.mfnx.net>, Paul A Vixie writes: > >>> Oh god, I hope not. RTT has never been an accurate predictor of end-to-end >>> performance. (Just ask anyone who bought into ping-based global server load >>> balancing.) ASPATH length is almost as bad (as a predictor) as RTT. >> >> well, it's the way icmp_echo is handeld in some vendor routers and >> sometime also the poor implementation of an IP stack on the echoing >> device which is a problem. > >no, that is not the problem. oh i admit that ping time jitter is ~random. >but even if it weren't, RTT doesn't drive performance, (bw*delay)-loss does. > And how does "delay" differ from RTT, except for the obvious constant factor? --Steve Bellovin, http://www.research.att.com/~smb

2 1

Re: Beer and Gear surprise
by Ukyo Kuonji 22 Feb '01

22 Feb '01

I disagree. Read my other post. The charter defines membership. Of course it is entirely too broad. As I interpret it, if you are a network operator, researcher or vendor, you may be a member of NANOG. The charter does not define community, only membership. --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. ----Original Message Follows---- From: abha <ahuja(a)wibh.net> To: Ukyo Kuonji <kawaii_iinazuke(a)hotmail.com> CC: <nanog(a)merit.edu> Subject: Re: Beer and Gear surprise Date: Thu, 22 Feb 2001 08:28:30 -0800 (PST) In regards to Merit, how NANOG is run and organized, etc... Merit has been running NANOG forever as part of a service to the community and has always tried to keep the community's best interest at heart (if you don't think this is happening, put it on your survey form) and there is no membership. It is really quite simple, if you don't like it, you don't have to come. There are other member-based organizations that might meet your needs. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

5 4

A new thread...
by Rich Sena 22 Feb '01

22 Feb '01

Martin Hannigan inlipstick and a t-shirt - discuss amongst yourselves I'm to vehklempt! -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

1 0