Re: 41/8 announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, there was an update on this topic on the AfNOG list. I thought nanog list should find this interesting. On May 24, 2006, at 7:00 AM, Mikisa Richard wrote: This thread has been dead for awhile now but it never was really solved. Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? - -end quote from afnog mailing list --- thanks On May 22, 2006, at 11:46 AM, Ernest B. M wrote: Apologies for duplicates] Dear Colleagues, Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. Reachability tests can be conducted with 41.223.252.1 as a target IP address. Kind Regards, Ernest, AfriNIC. -- gaurab /+9779851038080 gaurab at lahai dot com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEdAnbSo7fU26F3X0RAtpjAJ9Gnf7uDLFofrqsinGFSc6tQO8v6ACeIDvB 5QH2WGSazy09vlwWBpUZ5JE= =bEnl -END PGP SIGNATURE-
Re: 41/8 announcement
On 5/24/06, Gaurab Raj Upadhaya [EMAIL PROTECTED] wrote: Well, there was an update on this topic on the AfNOG list. I thought nanog list should find this interesting. yup see my followup to nanog earlier today -srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: AS12874 - FASTWEB
On May 24, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: Fastweb seems to think 41/8 is a dsl pool for its users in Turin Indeed. But that list is a bit old, they are also using 59/8 (in use in the APNIC region) and a few private DoD networks like 26/8 and 29/8: http://plany.fasthosting.it/dbmap.asp?table=Mappatura Some customers tried complaining, but I understand that this did not have any effect. -- ciao, Marco
Fwd: 41/8 announcement
This came in from someone in Italy.. -- Forwarded message -- From: * Date: May 24, 2006 11:15 AM Subject: Re: 41/8 announcement To: [EMAIL PROTECTED] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... Let me know if you need more information. (Feel free to repost this if needed, but please remove my name.) -- ciao, *** -- cheers Richard
Re: ISP compliance LEAs - tech and logistics [was: snfc21 sniffer docs]
The NANOG meeting archives are full of presentations as the result of very sophisticated network monitoring. Like most technology, it can be used for good and evil. You can't tell the motivation just from the technology. OK, so he says in a roundabout way that you are already paying for some sophisticated network monitoring and it probably won't cost you much to just give some data to the authorities. Sean, please drop this subject. You have no experience here and it's annoying that you keep making authoritative claims like you have some operational experience in this area. If you do, please do elaborate and correct me. From what I understand from the folks at SBC, you did not run harassing call, annoyance call, and LAES services. I would appreciate a correction. Huh!?!?!? Are you saying that people should buzz off from the NANOG list if they change jobs and their latest position isn't operational enough? Are you saying that people should not be on the NANOG list unless they have TELEPHONY operational experience? What is the world coming to!? --Michael Dillon
Re: private ip addresses from ISP
Does NANOG have a role in developing some best practices text that could be easily imcorporated into peering agreements and service contracts? ... RFC 2267 - RFC 2827 == Best Current Practice (BCP) 38 RFC 3013 == BCP 46 RFC 3704 == BCP 84 Are these followed? No, the IETF BCP's are not followed and part of the reason is that they are not written by network operators but often by vendors and academics. The fact is that the collective of network operations people (in North America at least) does not have any agreed set of BEST OPERATIONAL PRACTICES. There are various camps that promote various sets of rules which are often overly simplistic and cannot be 100% adhered to in practice. What we really need is a forum to discuss best operational practices and resolve all these various differences in opinion systematically. The end result should be a set of best practices that people really can follow with no exceptions. Of course this means that the best practices must incorporate various exceptions to the simple rules and explain when those exceptions are and are not appropriate. So again, I ask the question: Is NANOG an appropriate forum to develop some best practices text that could be incorporated into service agreements and peering agreements by reference in the same way that a software licence incorporates the GPL by referring to it? --Michael Dillon
Re: Fwd: 41/8 announcement
so how many ISPs will shun fastweb for hijacking address space? (please do -NOT- respond, its a retorical question...) --bill On Wed, May 24, 2006 at 11:37:12AM +0300, Richard Mikisa wrote: This came in from someone in Italy.. -- Forwarded message -- From: * Date: May 24, 2006 11:15 AM Subject: Re: 41/8 announcement To: [EMAIL PROTECTED] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... Let me know if you need more information. (Feel free to repost this if needed, but please remove my name.) -- ciao, *** -- cheers Richard
Re: ISP compliance LEAs - tech and logistics [was: snfc21 sniffer docs]
[EMAIL PROTECTED] wrote: The NANOG meeting archives are full of presentations as the result of very sophisticated network monitoring. Like most technology, it can be used for good and evil. You can't tell the motivation just from the technology. OK, so he says in a roundabout way that you are already paying for some sophisticated network monitoring and it probably won't cost you much to just give some data to the authorities. Sean, please drop this subject. You have no experience here and it's annoying that you keep making authoritative claims like you have some operational experience in this area. If you do, please do elaborate and correct me. From what I understand from the folks at SBC, you did not run harassing call, annoyance call, and LAES services. I would appreciate a correction. Huh!?!?!? Are you saying that people should buzz off from the NANOG list if they change jobs and their latest position isn't operational enough? Are you saying that people should not be on the NANOG list unless they have TELEPHONY operational experience? What is the world coming to!? --Michael Dillon The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. That makes sense with shifting points of view from IRA and Basque Separatists to the European Central Bank everybody can use the standart API and start listening. Of course nobody except the European Central Bank is allowed listening, but - who cares? I am told china too is very advanced. But I am shure North America will catch up fast. Or does he mean Operations, the IRA guys who are running the London Docklands eavesdropping facility, that connects europe via the glc fibre? /ranting ? remember where we started ??? Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: ISP compliance LEAs - tech and logistics
The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ISP compliance LEAs - tech and logistics
The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. You missed a line later in his message: Of course nobody except the European Central Bank is allowed listening, but - who cares? Sounds like typical lunatic ravings to me. I guess anything goes on this list now... --Michael Dillon
Re: ISP compliance LEAs - tech and logistics
[EMAIL PROTECTED] wrote: The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Institut européen des normes de télécommunication http://portal.etsi.org/docbox/Workshop/GSC/GSC10_RT_Joint_Session/00index.txt Doc. Name: gsc10_joint_10r1 File Name: gsc10_joint_10r1.ppt Title: Lawful Interception standardisation, the status of ETSi LI standards Source: Peter van der Arend, Chairman ETSI TC LI Reserved by: Mr. Julian Pritchard from ETSI Secretariat on 2005-08-29 at 14:02:04 (GMT +01:00) Allocations: 4.3: Security and Lawful Interception Content Type: none specified Abstract: none http://www.gliif.org/LI_standards/ts_102232v010101p.pdf This one gives an overview Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: Fwd: 41/8 announcement
Well, the noise helped some. We now have connectivity to fastweb net. On 5/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: so how many ISPs will shun fastweb for hijacking address space? (please do -NOT- respond, its a retorical question...) --bill On Wed, May 24, 2006 at 11:37:12AM +0300, Richard Mikisa wrote: This came in from someone in Italy.. -- Forwarded message -- From: * Date: May 24, 2006 11:15 AM Subject: Re: 41/8 announcement To: [EMAIL PROTECTED] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... Let me know if you need more information. (Feel free to repost this if needed, but please remove my name.) -- ciao, *** -- cheers Richard -- cheers Richard
Re: 41/8 announcement
On May 24, 2006, at 4:37 AM, Richard Mikisa wrote: [...] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... One of the points of NAT is to make renumbering easy. Silly them. I have a rule: Your network, your rules. If they want to be disconnected from Africa, you can't stop them. And they are not hijacking the /8, it is not announced on the 'Net. This is identical to a null route inside their ASN. I would never dream of telling them they cannot decide which netblocks should be routeable inside their own ASN. Fortunately, I have another rule: My network, my rules. If someone can find the real addresses for FastWeb uses for the NAT pool and post it here (and other *NOG lists), networks can ensure that FastWeb's end users will be unable to communicate with a lot more than a few African networks. I think the show of solidarity would be good for the 'Net. -- TTFN, patrick
Re: ISP compliance LEAs - tech and logistics
The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Institut européen des normes de télécommunication http://portal.etsi.org/docbox/Workshop/GSC/GSC10_RT_Joint_Session/00index.txt I see a list of documents. I see no sign that these documents are standards, nor that they are actually *implemented*. I know for a fact that the service provider I work for has not implemented this on the IP side. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ISP compliance LEAs - tech and logistics
On May 24, 2006, at 9:44 AM, [EMAIL PROTECTED] wrote: I see a list of documents. I see no sign that these documents are standards, nor that they are actually *implemented*. I know for a fact that the service provider I work for has not implemented this on the IP side. Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard. ;-) Best regards, Christian
Re: MAE-WEST - 55 S Market area equipment sourcing
Hello... On Tue, May 23, 2006 6:22 pm, Rodney Joffe said: snip Can anyone point me to a source in the 55 S Market area that might have the appropriate intelligent media conversion devices actually in stock, at a reasonable price, and not 1-2 days out? Bearing in mind that besides converting media, I have to convert speed for the Gbics? And I am trying to avoid the cost of getting two switches, and installing appropriate Gbics in them :-/ This is not in you area, but FFR in LA across the street from one wilshire, Lightsource1 has a small storefront. They stock GBICS, fiber, copper, various Cisco bits (backed by a stockpile of larger stuff). There is a phone number posted for the It's 2am and I need $part right now times. Rumor has it they will soon have free coffee and wireless. -- Christopher McCrory The guy that keeps the servers running [EMAIL PROTECTED] http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works.
Re: MAE-WEST - 55 S Market area equipment sourcing
On Wed, May 24, 2006 at 07:54:00AM -0700, Christopher McCrory wrote: This is not in you area, but FFR in LA across the street from one wilshire, Lightsource1 has a small storefront. They stock GBICS, fiber, copper, various Cisco bits (backed by a stockpile of larger stuff). There is a phone number posted for the It's 2am and I need $part right now times. Rumor has it they will soon have free coffee and wireless. Does ACE Hardware still sell UTP/coax/fiber, ends and crimpers on the ground floor of 60 Hudson? i always thought that was cool. i was thinking of putting a vending machine in 151 Front (Toronto), selling cables and bits for outrageous prices. -- [ Jim Mercerjim@reptiles.org +1 416 410-5633 ] [ I want to live forever, or die trying.]
Re: ISP compliance LEAs - tech and logistics [was: snfc21 sniffer docs]
At 04:58 AM 5/24/2006, [EMAIL PROTECTED] wrote: The NANOG meeting archives are full of presentations as the result of very sophisticated network monitoring. Like most technology, it can be used for good and evil. You can't tell the motivation just from the technology. OK, so he says in a roundabout way that you are already paying for some sophisticated network monitoring and it probably won't cost you much to just give some data to the authorities. Sean, please drop this subject. You have no experience here and it's annoying that you keep making authoritative claims like you have some operational experience in this area. If you do, please do elaborate and correct me. From what I understand from the folks at SBC, you did not run harassing call, annoyance call, and LAES services. I would appreciate a correction. Huh!?!?!? Are you saying that people should buzz off from the NANOG list if they change jobs and their latest position isn't operational enough? Are you saying that people should not be on the NANOG list unless they have TELEPHONY operational experience? What is the world coming to!? [ rescued from the killfile ] As far as archives being chock full of information, Chip Sharp of Cisco made a factual presentation on CALEA years back. The rest of the discussion has been mostly hyperbole. Emotional fodder on political agendas instead of technical, operational, or otherwise. I'd characterize 90% or more of it as junk. If I want to read about politics, I can open my newspaper with my coffee - and I do, but that's the extent I need to see it all day long. We're already bombarded with this stuff elsewhere. No, someone should not quit NANOG's list because they change jobs. Changing jobs has nothing to do with it. Being a subject matter expert is. It's arguable who the SME's here on the list are related to CALEA. There aren't more than 2 or 3 and they aren't usually talking about these types of posts. Not because there's a big secret to be kept. There isn't. It's all public. It's because the thread will always turn to politics and disinformation and it's a bad use of everyones time. Perhaps a bit too harsh on the prior response, but the quality of some of the posting here has become arguably low as of late. Maybe it's because of too much rain? I don't know, but NTP, geo-location, and CALEA have all been subject to this. /me back to our regularly scheduled programming --Michael Dillon -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: private ip addresses from ISP
On May 24, 2006, at 2:05 AM, [EMAIL PROTECTED] wrote: snip So again, I ask the question: Is NANOG an appropriate forum to develop some best practices text that could be incorporated into service agreements and peering agreements by reference in the same way that a software licence incorporates the GPL by referring to it? Ah, I think we all assumed you were kidding when you asked that! While I think NANOG *should* be the appropriate forum, I don't really think it will be -- there are too many personal agendas -- getting the community to agree on *anything* these days appears to be a losing proposition I suspect that a post suggesting we replace IP with a piece of wet spaghetti would: a: Get n replies agreeing b: Get n replies disagreeing c: Possibly generate a post that is trying to be useful. d: A fish (not a fish anything, just a random posting not related to anything on topic) e: Spawn a thread screaming Troll f: Get 2n replies asking if that will run on vendor X g: Get 2n replies suggesting that an alternate root / better SPAM detection / would fix all our woes h: Generate n^2 ad hominem attack threads. i: Be sidetracked into a request for a contact for company Y j: Get misinterpreted [supporting | blasting] someone's pet theory / idea / etc Even the fairly simple question of whether a network should emit packets with RFC1918 sourced packets (a topic I am declining to comment on) exhibited many of the above. While I think having some best practices text that could be incorporated into service agreements and peering agreements would be great I suspect this isn't the forum to generate such a thing -- unless it looks like: Best Common Practices (please circle appropriate field): 1: Interconnecting networks (agree to always) / (agree to never) / (agree to sometimes) emit packets with RFC1918 addresses 2: Interconnecting networks ( shall) / (shall not ) run some form of RPF 3: Interconnecting networks (will) / (won't) / (might) randomly depeer ... etc. Having some best practices text that could be incorporated into service agreements and peering agreements would be great -- lets how about setting up a forum for this? Warren (who is feeling very grumpy and cynical this morning -- and might take all the above back once the coffee sinks in) --Michael Dillon -- Real children don't go hoppity-skip unless they are on drugs. -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)
Re: ISP compliance LEAs - tech and logistics
Christian Kuhtz wrote: On May 24, 2006, at 9:44 AM, [EMAIL PROTECTED] wrote: I see a list of documents. I see no sign that these documents are standards, nor that they are actually *implemented*. I know for a fact that the service provider I work for has not implemented this on the IP side. French and german ISPs keep complaining about what it has cost them and they keep informing us (customers) that it is on us to pay the bill. I remember one german ISP who was helpful enough to mention the cost for spying in his bill. It was a mistake and the money was refunded ... Whenever mailservers are down here in germany somebody mentions the delay is because all email is routed via the german gouvernement again :) Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard. ;-) Best regards, Christian I just tested my NAT-router and made shure it is RFC 3514 compliant. Yes the NASTY bit is set :) Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: private ip addresses from ISP
On Wed, 24 May 2006 11:50:34 PDT, Warren Kumari said: d: A fish (not a fish anything, just a random posting not related to anything on topic) And this one will invariably start a trout/salmon/swordfish/octopus debate. pgpey06HNxilK.pgp Description: PGP signature
Re: ISP compliance LEAs - tech and logistics
On Wed, 24 May 2006 10:39:05 EDT, Christian Kuhtz said: Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard. Actually, it's Informational rather than Standards Track. However, since there were patches for both a *BSD variant and Linux, we can probably scare up two interoperable implementations so we can move it along Standards Track. :) pgpLpoDid5Z1t.pgp Description: PGP signature
Re: ISP compliance LEAs - tech and logistics
On May 24, 2006, at 3:27 PM, [EMAIL PROTECTED] wrote: On Wed, 24 May 2006 10:39:05 EDT, Christian Kuhtz said: Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard. Actually, it's Informational rather than Standards Track. Nitpicky bugger, good grief. ;-) It's an RFC, therefore it is gospel. ;-) However, since there were patches for both a *BSD variant and Linux, we can probably scare up two interoperable implementations so we can move it along Standards Track. :) Stop, Vladis, stop, you're scarying me. ;-)
Re: ISP compliance LEAs - tech and logistics
On Wed, 24 May 2006 15:27:56 -0400, [EMAIL PROTECTED] wrote: On Wed, 24 May 2006 10:39:05 EDT, Christian Kuhtz said: Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard. Actually, it's Informational rather than Standards Track. However, since there were patches for both a *BSD variant and Linux, we can probably scare up two interoperable implementations so we can move it along Standards Track. :) Except for routing protocols, you don't need running code for Proposed Standard. But yes, I received several implementation reports. I was also told that Junipers can almost do the filtering: Technically the CF does have the ability to see 'any bit in the first 21 bytes' of an IP packet... (I believe it's 21 bytes at least). The limitations on the software installed, however, keep you from doing the arbitrary bit field/offset business. See http://www.cs.columbia.edu/~smb/3514.html -- and note that it already mentions Lawful Intercept. Yes, it's all from real email --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: private ip addresses from ISP
Date: Wed, 24 May 2006 15:26:15 -0400 From: Valdis.Kletnieks d: A fish (not a fish anything, just a random posting not related to anything on topic) And this one will invariably start a trout/salmon/swordfish/octopus debate. ...at which point someone interjects that an octopus is a mollusk... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
