October 2002 - Test - lists.nanog.org

complexity draft
by Randy Bush 28 Oct '02

28 Oct '02

draft-ymbk-arch-guidelines-05.txt

1 0

RE: NMS/OSS commercial software : short summary from NANOG replies
by Daniska Tomas 28 Oct '02

28 Oct '02

do you mean kind of "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD" :)))) -- deejay > -----Original Message----- > From: Nipper, Arnold [mailto:arnold@nipper.de] > Sent: 28. októbra 2002 15:51 > To: Petri Helenius; nanog(a)merit.edu; m.rapoport(a)completel.fr > Subject: Re: NMS/OSS commercial software : short summary from > NANOG replies > > > > Expansion of nothing is still nothing. Others call it <insert > your favorite OS> ... > > > Arnold > > > > > That is very short summary, would you care to expand a little bit? > > > > Pete > > > > > > > > Hello, > > > First of all, thanks for all the answers that I received > from the list. > > > Some of you asked me a feedback on the answers received, > so here it is : > > > > > > > > > > > > > > > > > > >

1 0

NMS/OSS commercial software : short summary from NANOG replies
by m.rapoport＠completel.fr 28 Oct '02

28 Oct '02

Hello, First of all, thanks for all the answers that I received from the list. Some of you asked me a feedback on the answers received, so here it is :

3 2

NANOG26 IPv6 instructions
by itojun＠itojun.org 27 Oct '02

27 Oct '02

http://www.kame.net/nanog26/ itojun

1 0

NANOG26: IPv6 unreachable prefix advertised
by itojun＠itojun.org 27 Oct '02

27 Oct '02

it looks that there's unreachable IPv6 prefix advertised at the venue. please stop this router advertisement (2001:468:1420:f::/64), or fix conectivity... with this configuration i can't use IPv6 to connect to my home. itojun itojun[coconut:~] traceroute6 -n -q1 2001:468:1420:f:220:e0ff:fe8d:3a8c traceroute6 to 2001:468:1420:f:220:e0ff:fe8d:3a8c (2001:468:1420:f:220:e0ff:fe8d:3a8c) from 2001:298:308:1:2ae:d0ff:fe00:3b, 30 hops max, 12 byte packets 1 2001:298:308:1:200:24ff:fec0:55de 0.878 ms 2 3ffe:8360:1000::2000 5.885 ms 3 3ffe:8360:1000::1 5.252 ms 4 3ffe:8360:1000:1::3 6.879 ms 5 3ffe:8360:0:1000::1:1 7.379 ms 6 2001:200:0:1800:230:48ff:fe41:4e50 5.001 ms 7 2001:200:0:1800::9c4:2 5.16 ms 8 2001:200:0:1800::9c4:0 5.142 ms 9 2001:200:0:6c01:290:27ff:fe3a:d8 5.557 ms 10 2001:200:0:6c01:209:11ff:fedb:19fe 144.071 ms 11 2001:468:ff:b17::1 390.569 ms 12 2001:468:ff:b17::2 389.938 ms 13 2001:468:ff:1317::1 390.554 ms 14 2001:468:ff:1213::1 402.714 ms 15 2001:468:ff:6c1::1 390.262 ms 16 2001:468:ff:306::1 397.108 ms 17 2001:468:ff:354::2 419.125 ms !A

1 0

2 breaks on TAT 14
by Jesper Skriver 27 Oct '02

27 Oct '02

Hi, It seems that there is 2 breaks on TAT 14, one between Manasquan (US) and Blaabjerg (DK) and one somewhere between Blaabjerg and Pentewan, rumors say somewhere in Holland. The first seems to be some days old, the second failed around 12:20 CET yesterday. Rumors also say one of failures will be fixed around 18:00 CET today. Does anyone have more details ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

1 0

Re: How to secure the Internet in three easy steps
by Paul Vixie 27 Oct '02

27 Oct '02

> > not just the bad people. all the people. a network with 2 or 3 in place > > is useless. there is no way to make 2 or 3 happen. > As part of their anti-spam efforts, several providers block SMTP port > 25, and force their subscribers to only use that provider's SMTP > relay/proxy to send mail. Why not extend those same restrictions to > other (all) protocols? each protocol that becomes as widely abused as smtp has been, will be blocked, since blocking will save the ISP money. you also mentioned proxying of web traffic, which due to banner ads often makes the ISP money. this whole thing is really about money. but "1" isn't getting done because the money that could be saved is by ISP "B" whereas the money which must be spent is by ISP "A". so, the nondeployment of BCP38 is all about money, too. the thing i'm trying to work my way back to is that "2" and "3" can be argued to restrict desireable freedoms (like reaching SMTP or WWW servers without being forced to use a local proxies) whereas "1" has no arguments against it, or at least no arguers here on nanog today. why lump them all three together? PS. you mentioned AOL, which uses IP framing in order to leverage off of the IP stack already present in their customer's computers, but other than that it's a captive application. what addresses are used doesn't really matter there in any global sense, nor proxies or nats or whatever.

5 5

Re: [Re: the cost of carrying routes]
by Ratul Mahajan 27 Oct '02

27 Oct '02

On Tue, 15 Oct 2002, Joshua Smith wrote: > they could probably make some good money if they also charged for 'leaky' > networks - however, i think the sentiment amongst their customers would > not be favorable (you charge for misconfigurations? some nerve you have) > it is probably one of those long term goals that you will almost never be > able to convince the powers-that-be of undertaking. but i do pay for mistakes i make in other industries -- i pay for late credit card payments and for parking where i should not. and these fines keep me on my feet, and i try to blunder less often. why are running networks different? whats the incentive today to not make mistakes while running a network, especially mistakes those that don't hurt yourself much? there is only some amount of social pressure i think. wouldn't configuration errors go down if providers/peers were to charge less for well-managed networks, or charge more for poorly managed networks? convincing customers just might be a matter of saying the right things. for instance, "our services cost $Z in general, but if we find that you manage your network well (some quantification), you pay only $Z-z (and optionally, if you manage it very poorly, you pay $Z+z')." -- ratul ps: since i don't run networks myself, all of this may be something that is obviously asinine. would be great if someone was to point out if that is the case, and why. > Ratul Mahajan <ratul(a)cs.washington.edu> wrote: > > > > > > i have related question to ron's (a bit hypothetical but interesting > > nonetheless). > > > > if isps charged for bgp announcements, would the number of announcements > > that shouldn't be made (e.g., those due to configuration errors and poor > > operational practices) go down? > > > > -- ratul > > > they could probably make some good money if they also charged for 'leaky' > networks - however, i think the sentiment amongst their customers would > not be favorable (you charge for misconfigurations? some nerve you have) > it is probably one of those long term goals that you will almost never be > able to convince the powers-that-be of undertaking. i know i am having > a very difficult time convincing management that our network needs some > help - although after several recent, fairly successful attacks, they are > starting to listen. > > joshua > > > > > > -------------- > > > > On Mon, 14 Oct 2002, Ron da Silva wrote: > > > > > > > > > > > Some ISPs charge for actual bits carried (peak usage, actual count, > > > whatever) in addition to or instead of per port/circuit charges. > > > > > > Do any ISPs charge based on the number of announcements a customer > > > advertises? > > > > > > If downstream advertisements became mainly smaller prefixes (say /24) > > > that were not aggregatable by you as their upstream ISP, would you > > > answer the above question differently? > > > > > > -ron > > > > > > > > > "Walk with me through the Universe, > And along the way see how all of us are Connected. > Feast the eyes of your Soul, > On the Love that abounds. > In all places at once, seemingly endless, > Like your own existence." > - Stephen Hawking - > >

3 2

Re: How to secure the Internet in three easy steps
by Paul Vixie 26 Oct '02

26 Oct '02

> Source address validation, or more generally anti-spoofing filters, do > not require providers maintain logs, perform content inspection or > install firewalls. But source address validation won't stop attacks, > viruses, child porn, terrorists, gambling, music sharing or any other > evil that exists in the world. So the proposal "1" gets extended to > include other stuff. It gives better ROI when more than SAV is included. i can see how this could happen. however, i do not think that it is the reason why SAV is not gettign deployed.

1 0

Some sort of outage going on with AOL or their peers?
by Gil Cohen 26 Oct '02

26 Oct '02

I can't reach AOL's mailservers at all from Cogent, and a ping from MAE-East looking glass ( http://nitrous.digex.net/mae/mae-lg.html ) shows that it's not working either It seems to work from the PAIX looking glass though. What a fun day.... Oct 26 14:33:33 lostgeeks postfix/smtp[54035]: connect to mailin-04.mx.aol.com[64.12.136.153]: Operation timed out (port 25) Oct 26 14:34:48 lostgeeks postfix/smtp[54035]: connect to mailin-01.mx.aol.com[64.12.137.89]: Operation timed out (port 25) Oct 26 14:35:31 lostgeeks postfix/smtp[54193]: connect to mailin-03.mx.aol.com[64.12.136.249]: Operation timed out (port 25) Oct 26 14:36:03 lostgeeks postfix/smtp[54035]: connect to mailin-01.mx.aol.com[152.163.224.26]: Operation timed out (port 25) Oct 26 14:36:46 lostgeeks postfix/smtp[54193]: connect to mailin-04.mx.aol.com[64.12.137.121]: Operation timed out (port 25) --from cogent-- traceroute 64.12.137.121 traceroute to 64.12.137.121 (64.12.137.121), 64 hops max, 44 byte packets 1 yoda.saturnbandwidth.net (66.250.215.1) 61.467 ms 0.251 ms 0.164 ms 2 f29.ba01.b002802-1.mia01.atlas.cogentco.com (38.112.0.1) 0.680 ms 0.660 ms 0.675 ms 3 g0-2.core01.mia01.atlas.cogentco.com (66.28.6.41) 0.642 ms 0.468 ms 0.415 ms 4 p5-0.core01.jax01.atlas.cogentco.com (66.28.4.65) 8.241 ms 8.361 ms 8.578 ms 5 p5-0.core01.atl01.atlas.cogentco.com (66.28.4.138) 14.867 ms 31.769 ms 14.649 ms 6 g3-0.pr1.atl01.netrail.net (66.28.28.202) 14.365 ms 14.383 ms 14.427 ms 7 66.185.150.1 (66.185.150.1) 14.602 ms 14.283 ms 14.404 ms 8 bb2-atm-P0-0.atdn.net (66.185.147.197) 14.819 ms 14.696 ms 14.599 ms 9 bb2-cha-P6-0.atdn.net (66.185.152.31) 19.706 ms 19.489 ms 19.615 ms 10 * * * ---- Thanks, Gil -- Gil Cohen <gcohen(a)saturnbandwidth.net> | SENIOR NETWORK ENGINEER | SATURN BANDWIDTH & FIBER, INC. | (o) 954-438-7000x124 (c) 954-347-0615 |

1 1